For now, if a plugin dies before lightningd for whatever reason while having registered a hook, lightningd will hang forever when sending a "hook request" to the plugin. We might want to rely more on plugin for more crucial operations (for example, RPC wallet locking, Bitcoin network interface), hence a special kind of plugins -"crucial" plugins- might be defined so that if they die, lightningd聽does too.
lightningd isnt stuck anymore as of https://github.com/ElementsProject/lightning/issues/3496, and https://github.com/ElementsProject/lightning/issues/3213#issuecomment-568973022 is overall a better proposal.
As an added idea, we should mark plugins that are part of our distribution, and which implement commands that were previously built-in to lightningd, as crucial as well. #3373 shows that some boutique installations processes do not properly install our distributed plugins.
This might not necessarily be the same as the "crucial" concept described here, however. We need to be able to mark plugins as needed by lightningd even at the start, i.e. we have an option flag --crucial-plugin=foo which causes lightningd to exit immediately if those plugins never got started in the first place, and add our builtin plugins to that set, so that installations missing our "builtin" plugins will fail immediately.
Most helpful comment
As an added idea, we should mark plugins that are part of our distribution, and which implement commands that were previously built-in to
lightningd, as crucial as well. #3373 shows that some boutique installations processes do not properly install our distributed plugins.This might not necessarily be the same as the "crucial" concept described here, however. We need to be able to mark plugins as needed by
lightningdeven at the start, i.e. we have an option flag--crucial-plugin=foowhich causeslightningdto exit immediately if those plugins never got started in the first place, and add our builtin plugins to that set, so that installations missing our "builtin" plugins will fail immediately.