Dynamic plugins don't get any options.

[fiatjaf]

If a plugin is restarted with plugin stop then plugin start it gets empty "options" in the init method call, doesn't matter if the options exist or if they are required.

I tried to circumvent this by calling listconfigs and trying to pick up the options that should be on init from there, but they had vanished from that list too after plugin stop.

[cdecker]

Kind of hard to say that this isn't the intended behavior: we free all resources that were used by a plugin if the plugin exits or is stopped by us, this includes the options.

Command line options don't really mesh well with dynamic plugins at all, and I'm tempted to make non-dynamic the default, so developers need to opt-in to the more complex dynamic behavior. FWIW it's not that complicated to implement a shim that acts like a normal (non-dynamic) plugin towards lightningd but allows restarting the underlying plugin, while keeping the configuration including the options active (and more importantly buffering notifications and hook calls). You can find an example of how this works here: https://github.com/lightningd/plugins/tree/master/autoreload

Another trick that the autoreload plugin does is to look at the parent process' command line and extract the options from there. That's rather an extreme workaround, but it works.

[darosior]

I don't see this as an unexpected behaviour. It seems to me to be natural for a non startup-only plugin not to rely on a startup option.
In addition, we don't allow startup-only (static) plugins to be stop and we don't allow unrecognized startup options :

$ lightningd --aaaa
lightningd: --aaaa: unrecognized option

So I think it's (most of the time) bad design for a dynamic plugin to use startup options which are maybe here, maybe not.

I tried to circumvent this by calling listconfigs and trying to pick up the options that should be on init from there, but they had vanished from that list too after plugin stop.

We free the dangling option when non startup-only plugins (the default) are plugin stoped.

[fiatjaf]

Ok, this may not be unexpected, but it certainly is undesirable!

[darosior]

Why is it undesirable ? Why cannot you use a command line parameter in place of the option ? I can see the autoclean plugin as a counter-example but it can probably be made a static plugin. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le mercredi, juin 24, 2020 12:13 AM, fiatjaf <notifications@github.com> a écrit :

…

Ok, this may not be unexpected, but it certainly is undesirable! — You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#3731 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFLK3F4JS64W5SOBZYHLEG3RYESIRANCNFSM4NDAYXUA).

[fiatjaf]

So if you pass a parameter on the command line when starting lightningd it will be persisted and always accessible from dynamic plugins?

I thought the cli parameters and the config file were treated as exactly the same.

[darosior]

So if you pass a parameter on the command line when starting lightningd it will be persisted and always accessible from dynamic plugins?

No, that's kind of the point isn't it ?

I thought the cli parameters and the config file were treated as exactly the same.

No, `lightningd`'s startup parameters only affect plugins known to `lightningd` at that time (i.e. plugins started at startup).

…

— You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#3731 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFLK3FYGLF3Z77GX22IGJ5LRYEUV3ANCNFSM4NDAYXUA).

[fiatjaf]

Ok, let's start again.

I don't understand why can't settings (either passed as cli params or in the config file) be persisted by lightningd and directed to each plugin as they're request it through getmanifest. Why?

Also, why do you think dynamic plugins are so different from non-static plugins that they can't get options from lightningd config?

[ZmnSCPxj]

I don't understand why can't settings (either passed as cli params or in the config file) be persisted by lightningd and directed to each plugin as they're request it through getmanifest. Why?

I think the root of the confusion here is that lightningd allows plugins to add their own command-line arguments to the lightningd command line / config file.

plugins/autoclean, for example, adds --autocleaninvoice-cycle and --autocleaninvoice-expired-by command line parameters. lightningd does not know them naturally, yet doing lightningd --help will list them (because even something as simple as --help will load plugins!).

On the other hand, command-line arguments that neither lightningd knows directly, nor were indicated by any plugins, are rejected at command-line parsing stage and error out immediately.

Thus, plugins which are not loaded at the start cannot add their own command-line arguments to lightningd before lightningd has to process command-line arguments. This implies dynamic plugins, which are not loaded at lightningd startup, cannot receive command-line arguments, because they cannot tell lightningd that those command line arguments are valid and should be passed to the plugin.

We need to reject command-line arguments we do not recognize at startup because if the user misspells a command-line argument, we do not want to silently accept it, assuming it is a command-line argument that a dynamic plugin will query for later; so we error out immediately on an unrecognized command-line argument. So only plugins that get loaded right from the start can feasibly provide command-line arguments, because they already exist at that point.