[c-lightning] adding new commands to lightning-cli
Sarat G
sarath.ginjupalli89 at gmail.com
Thu Dec 13 23:13:02 AEDT 2018
Hi Christian,
Upon adding the command success the assertion has been gone.
Here is the function snippet which I had written and its working fine.
>
>> static void json_peer_channel_state(struct command *cmd, const char
>> *buffer,
>
> const jsmntok_t *params)
>
> {
>
> struct json_result *response = new_json_result(cmd);
>
> jsmntok_t *idtok;
>
> char buf[100];
>
> sqlite3_stmt *stmt;
>
> int channel_state=-1;
>
> if (!json_get_params(cmd, buffer, params,
>
> "id", &idtok,
>
> NULL)) {
>
> return;
>
> }
>
> memcpy(buf,buffer + idtok->start,idtok->end - idtok->start);
>
> buf[idtok->end - idtok->start]='\0';
>
> printf("\n%s:%d:id:%s",__FUNCTION__,__LINE__,buf);
>
> stmt = db_prepare(cmd->ld->wallet->db,
>
> "SELECT state"
>
> " FROM channels"
>
> " Where id IN "
>
> " (SELECT id"
>
> " FROM peers"
>
> " WHERE lower(hex(node_id))=?);");
>
> sqlite3_bind_text(stmt, 1, buf, strlen(buf), SQLITE_TRANSIENT);
>
> while (sqlite3_step(stmt) != SQLITE_DONE) {
>
> int i;
>
> int num_cols = sqlite3_column_count(stmt);
>
> for (i = 0; i < num_cols; i++)
>
> {
>
> switch (sqlite3_column_type(stmt, i))
>
> {
>
> case (SQLITE3_TEXT):
>
> printf("%s, ", sqlite3_column_text(stmt, i));
>
> break;
>
> case (SQLITE_INTEGER):
>
> channel_state=sqlite3_column_int(stmt, i);
>
> break;
>
> case (SQLITE_FLOAT):
>
> printf("%g, ", sqlite3_column_double(stmt, i));
>
> break;
>
> default:
>
> break;
>
> }
>
> }
>
> }
>
> sqlite3_finalize(stmt);
>
> json_object_start(response, NULL);
>
> json_add_num(response, "channel-state", channel_state);
>
> json_object_end(response);
>
> command_success(cmd, response);
>
> }
>
>
and is registered as follows:
> static const struct json_command peer_channel_state = {
"peer-channel-state",
json_peer_channel_state,
"Find the state of the channel with the peer {id}"
};
AUTODATA(json_command, &peer_channel_state);
Thank You.
Regards,
Sarat G
On Thu, Dec 13, 2018 at 5:29 PM Christian Decker <decker.christian at gmail.com>
wrote:
> Hi Sarat,
>
> just to be sure, this is on an unmodified version of c-lightning, and
> `peer-channel-state` is implemented as a plugin with JSON-RPC
> passthrough?
>
> The assertion that is mentioned in the backtrace makes sure that we have
> acknowledged that the given JSON-RPC command is still pending, or was
> completed. The JSON-RPC passthrough correctly marks the incoming request
> as still pending after forwarding the request to the plugin here [1],
> and I can't see a way around it, hence my questions above.
>
> Cheers,
> Christian
>
> [1]
> https://github.com/ElementsProject/lightning/blob/master/lightningd/plugin.c#L688
>
> Sarat G <sarath.ginjupalli89 at gmail.com> writes:
> > Hi ZmnSCPxj,
> >
> > Sorry for the late reply, I overlooked the mail. I'm implementing few of
> > the commands mentioned below:
> >
> > 1. invoice-count: Returns the count of the invoices
> > 2. delete-all-invoices: Deletes all the existing invoices
> > 3. peer-channel-state: Returns the state of the channel for the given
> > peer_id.
> >
> > As mentioned by Christian, for the commands to which I don;t need to pass
> > arguments I was able to implement them successfully. But for implementing
> > the command 'peer-channel-state' I need to pass peer_id as parameter.
> when
> > I passed so the it's crashing in the lightningd.
> >
> > Below is the crash log, while passing parameters do we need to handle
> them
> > at the lightningd?
> >
> > root at sg777-1 ~/lightning/cli # ./lightning-cli peer-channel-state
> >
> "03943d572eb97ac78055cf4c708660228a60b2956fdcfeaaceba5551f98e92e727"lightningd:
> > lightningd/jsonrpc.c:480: parse_request: Assertion `c->pending'
> > failed.2018-12-13T03:07:34.086Z lightningd(14958): FATAL SIGNAL 6
> > RECEIVED2018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > lightningd/log.c:494 (log_crash)
> > 0x55a79691c9932018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > (null):0 ((null)) 0x7ffae5b3cf1f2018-12-13T03:07:34.103Z
> > lightningd(14958): backtrace: (null):0 ((null))
> > 0x7ffae5b3ce972018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > (null):0 ((null)) 0x7ffae5b3e8002018-12-13T03:07:34.103Z
> > lightningd(14958): backtrace: (null):0 ((null))
> > 0x7ffae5b2e3992018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > (null):0 ((null)) 0x7ffae5b2e4112018-12-13T03:07:34.103Z
> > lightningd(14958): backtrace: lightningd/jsonrpc.c:480 (parse_request)
> > 0x55a796918cba2018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > lightningd/jsonrpc.c:645 (read_json)
> > 0x55a79691954a2018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > ccan/ccan/io/io.c:59 (next_plan)
> > 0x55a79696c3002018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > ccan/ccan/io/io.c:387 (do_plan) 0x55a79696cdfd2018-12-13T03:07:34.103Z
> > lightningd(14958): backtrace: ccan/ccan/io/io.c:397 (io_ready)
> > 0x55a79696ce3b2018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > ccan/ccan/io/poll.c:310 (io_loop)
> > 0x55a79696e8032018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > lightningd/lightningd.c:407 (main)
> > 0x55a79691b0a12018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > (null):0 ((null)) 0x7ffae5b1fb962018-12-13T03:07:34.103Z
> > lightningd(14958): backtrace: (null):0 ((null))
> > 0x55a7969099392018-12-13T03:07:34.103Z lightningd(14958): backtrace:
> > (null):0 ((null)) 0xffffffffffffffff
> > Fatal signal 6. 0x55a79691ca91 log_crash
> > lightningd/log.c:5200x7ffae5b3cf1f ???
> > ???:00x7ffae5b3ce97 ???
> > ???:00x7ffae5b3e800 ???
> > ???:00x7ffae5b2e399 ???
> > ???:00x7ffae5b2e411 ???
> > ???:00x55a796918cba parse_request
> > lightningd/jsonrpc.c:4800x55a79691954a read_json
> > lightningd/jsonrpc.c:6450x55a79696c300 next_plan
> > ccan/ccan/io/io.c:590x55a79696cdfd do_plan
> > ccan/ccan/io/io.c:3870x55a79696ce3b io_ready
> > ccan/ccan/io/io.c:3970x55a79696e803 io_loop
> > ccan/ccan/io/poll.c:3100x55a79691b0a1 main
> > lightningd/lightningd.c:4070x7ffae5b1fb96 ???
> > ???:00x55a796909939 ???
> > ???:00xffffffffffffffff ???
> > ???:0
> > Log dumped in crash.log
> > lightning-cli: Non-object response ''[1]+ Aborted
> > (core dumped) ../lightningd/lightningd
> >
> >
> > Thank You.
> >
> > Regards,
> > Sarat G
> >
> >
> >
> >
> > On Fri, Dec 7, 2018 at 12:50 PM ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> >
> >> Good morning Sarat,
> >>
> >> What are you querying on the database?
> >> If you find it useful, it might be that others find it useful, so it is
> >> best if you feed it back to us upstream what extra command you made.
> >> It might also be possible, as cdecker said, that, extra command can be
> >> built from existing commands, and so it is better to put in some plugin
> >> instead.
> >>
> >> Regards,
> >> ZmnSCPxj
> >>
> >>
> >> Sent with ProtonMail <https://protonmail.com> Secure Email.
> >>
> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> >> On Friday, December 7, 2018 2:30 PM, Sarat G <
> >> sarath.ginjupalli89 at gmail.com> wrote:
> >>
> >> Hi Christian,
> >>
> >> Thank you very much for the help, now I'm able to add the commands
> >> successfully by registering it with AUTODATA. Since I'm running the
> >> customised queries on the database now I'm registering my methods with
> >> AUTODATA and doing.
> >>
> >> Prior to this, I'm opening the `lightningd.sqlite3` file from the
> program.
> >> But the problem which I encountered is if I make an RPC call the DB gets
> >> locked and that sometimes preventing me to access the DB directly from
> the
> >> same process.
> >>
> >> Anyways I written few queries and registered them with AUTODATA and
> there
> >> are working fine.
> >>
> >> Thank you once again.
> >>
> >> Regards,
> >> Sarat G
> >>
> >>
> >>
> >>
> >> On Thu, Dec 6, 2018 at 7:50 PM Christian Decker <
> >> decker.christian at gmail.com> wrote:
> >>
> >>> Hi Sarat,
> >>>
> >>> `AUTODATA` will take care of registering the json command with the
> >>> JSON-RPC framework and you should be able to see your command with
> >>> `lightning-cli help` after recompiling and restarting. The `struct
> >>> json_command` that you registered with `AUTODATA` contains the method
> >>> name and the function to be called when a request matching that method
> >>> name comes in. The compiler should be able to help you with the
> >>> signature of the function that we expect.
> >>>
> >>> Notice that if the information you require is exposed in some other
> way,
> >>> you can also write a plugin, instead. Plugins can be written in
> whatever
> >>> language you want, and can register options and JSON-RPC methods as
> well
> >>> (more to come in future). So if you don't need information that is not
> >>> otherwise exposed that might be a good option (you'd need to run the
> >>> unreleased `master` version though).
> >>>
> >>> Cheers,
> >>> Christian
> >>>
> >>> Sarat G <sarath.ginjupalli89 at gmail.com> writes:
> >>> > Hi,
> >>> >
> >>> > As part of my project requirement, i got to need the command that
> >>> returns
> >>> > the status of the channel by taking input as peer id. For that I
> >>> written up
> >>> > the necessary logic and lined it using AUTODATA. My doubt is on the
> >>> > lightningd side at which part do I need to add the logic to process
> the
> >>> > command information sent by the lightning-cli.
> >>> >
> >>> > Can someone please provide me some insights into adding a single
> >>> command to
> >>> > the lightning-cli repo.
> >>> >
> >>> > Thanks in advance.
> >>> >
> >>> > Regards,
> >>> > Sarat G
> >>> > --
> >>> > c-lightning mailing list
> >>> > c-lightning at lists.ozlabs.org
> >>> > https://lists.ozlabs.org/listinfo/c-lightning
> >>>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/c-lightning/attachments/20181213/122841eb/attachment-0001.html>
More information about the c-lightning
mailing list