GNU bug report logs -
#26830
Allow services to implement a 'reload' action
Previous Next
Full log
Message #49 received at 26830 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Heya,
>
> Clément Lassieur <clement <at> lassieur.org> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>
> [...]
>
>>> However, I think ‘reload’ might be confusing since in fact it doesn’t
>>> load Scheme code, contrary to what “herd load root foo.scm” does (maybe
>>> that’s what you meant?). In fact it’s closer to what “herd restart
>>> foo” does.
>>>
>>> What about changing the name to ‘reconfigure’ or ‘upgrade’ to avoid the
>>> confusion?
>>
>> I think it's going to be even more confusing because the other init
>> systems (systemd, sysvinit) all call it 'reload'. And, well, people are
>> probably more familiar with Systemd's 'reload' than with Shepherd's
>> 'reload root' :) WDYT?
>
> I think it’s a valid argument! However, if the choice is between
> internal consistency (on the use of the word “load” in Shepherd
> commands) and the rule of least surprise (choosing command names similar
> to those of other programs), I would favor internal consistency, I
> think. WDYT?
Ok! I like 'upgrade'.
>>> If the action took an argument, we could do:
>>>
>>> herd reconfigure nginx /gnu/store/…-new-config.conf
>>>
>>> which would translate to:
>>>
>>> nginx -s reload -c /gnu/store/…-new-config.conf
>>>
>>> Probably our best option.
>>
>> I don't see the point. If the service has already been reloaded by the
>> 'guix system reconfigure' command (let's assume it does, but I know it
>> doesn't currently reload nor restart sevices...), why would a user want
>> to reload it again with the 'herd' command? Or maybe you want this
>> feature as a workaround while the 'guix system reconfigure' that reloads
>> services isn't implemented?
>
> Sorry, I wasn’t clear. Action can take arguments; most don’t, but some
> do (like ‘herd start cow-store /mnt’ when installing GuixSD.) What I’m
> suggesting here is to add one/several arguments to this reload/upgrade
> action. The meaning of these arguments would be defined by the service
> itself.
>
> For nginx, there could be one argument (the config file) or two (the
> config file and the nginx executable file name). The reload/upgrade
> action would do “nginx -s reload -c …” and so on.
>
> The ‘upgrade-shepherd-services’ procedure would automatically call the
> reload/upgrade action with the right arguments. For that, it needs to
> know what the arguments are. An option would be to add an
> ‘upgrade-arguments’ field to <shepherd-service> that would return the
> arguments to pass to the upgrade action.
>
> Does that make sense?
Yes! Thank you :)
This bug report was last modified 3 years and 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.