Implementation concept for additional service commands e.g. reloading

[james-knippes]

In the conversation of the pull request #176 , which implements service signalling, the question of a general 'service reloading' feature came up. Not to be confused with reloading the dinit service definition/configuration, but an actual configuration file the running process/service uses, like nginx feature to reload website configuration.

I suppose many services would benefit from having extra commands in general. Examples are nginx feature of upgrading the executable in place or wvkbd's feature of toggling visibility of the onscreen keyboard.

@q66 suggested we may add reload-signal = hup and/or reload-command = something to the configuration.

I would like propose a more generalised approach. Adding arbitrary extra commands in the pattern command-$commandname = someting and signal-$commandname = signalname/number.

Example (nginx):

type              = process
command           = /usr/bin/nginx -g "daemon off;"
command-something = /usr/local/bin/nginx-something.sh $VAR
signal-reload     = SIGHUP
smooth-recovery   = true
logfile           = /var/log/dinit/nginx.log
waits-for         = loginready

Run via dinitctl command something nginx and dinitctl command reload nginx.

I propose the commands to all be simple one-shot commands and their state is not tracked by dinit. Dinit should only ensure that commands are not started at the same time. I can think of a simple queue of commands, which is processed successively.

Those commands could benefit from variable substitution. Currently there seems to only be support for substitution at service load time. Some substitution with runtime information like pid would also be pretty helpful.

[q66]

this sounds like hugely overdoing it for little actual benefit, while also making the common useful case (which is reloading service configuration) less convenient to use, while also making the format less intuitive to read

[davmac314]

Apologies for letting this slip. While I'm not completely against the idea of supporting arbitrary commands for services, I do agree with q66 in regards to the configuration. I'm not keen on setting names which encode part of the setting value semantics. Something like:

service-command = reload signal HUP
service-command = compactdb command /usr/bin/program --compact-database

... would be reasonable I think.

I don't at this stage plan to implement this myself.