[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26830: Allow services to implement a 'reload' action
From: |
Clément Lassieur |
Subject: |
bug#26830: Allow services to implement a 'reload' action |
Date: |
Fri, 12 May 2017 10:57:47 +0200 |
User-agent: |
mu4e 0.9.18; emacs 25.2.1 |
Ludovic Courtès <address@hidden> writes:
> Heya,
>
> Clément Lassieur <address@hidden> skribis:
>
>> Ludovic Courtès <address@hidden> 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 :)