From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d95tm-0000tg-QS for guix-patches@gnu.org; Fri, 12 May 2017 04:26:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d95ti-0000N2-3g for guix-patches@gnu.org; Fri, 12 May 2017 04:26:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:36992) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d95ti-0000Mk-09 for guix-patches@gnu.org; Fri, 12 May 2017 04:26:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d95th-0000MJ-RL for guix-patches@gnu.org; Fri, 12 May 2017 04:26:01 -0400 Subject: bug#26830: Allow services to implement a 'reload' action Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87d1bjtlpd.fsf@lassieur.org> <86vapa6nyi.fsf@gmail.com> <87vap7kryj.fsf@gnu.org> <874lwrq9em.fsf@lassieur.org> Date: Fri, 12 May 2017 10:25:09 +0200 In-Reply-To: <874lwrq9em.fsf@lassieur.org> ("=?UTF-8?Q?Cl=C3=A9ment?= Lassieur"'s message of "Fri, 12 May 2017 01:08:17 +0200") Message-ID: <87inl6trbu.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Cc: 26830@debbugs.gnu.org Heya, Cl=C3=A9ment Lassieur skribis: > Ludovic Court=C3=A8s writes: [...] >> However, I think =E2=80=98reload=E2=80=99 might be confusing since in fa= ct it doesn=E2=80=99t >> load Scheme code, contrary to what =E2=80=9Cherd load root foo.scm=E2=80= =9D does (maybe >> that=E2=80=99s what you meant?). In fact it=E2=80=99s closer to what = =E2=80=9Cherd restart >> foo=E2=80=9D does. >> >> What about changing the name to =E2=80=98reconfigure=E2=80=99 or =E2=80= =98upgrade=E2=80=99 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=E2=80=99s a valid argument! However, if the choice is between internal consistency (on the use of the word =E2=80=9Cload=E2=80=9D in Shep= herd commands) and the rule of least surprise (choosing command names similar to those of other programs), I would favor internal consistency, I think. WDYT? We have a nice bike shed to paint here. :-) >> Some comments: >> >> + #:actions (make-actions >> + (reload >> + "Reload the service's configuration f= iles." >> + #$(shepherd-service-reload service)))= ))))) >> >> Here I think we should only define the action when it has a non-#f >> value. That way we can distinguish between services that have a useful >> reload/reconfigure/upgrade action and those that don=E2=80=99t; in the l= atter >> case, we simply use =E2=80=98restart=E2=80=99 when upgrading. > > Ok. But right now IIRC we don't even use restart after a system > reconfigure, probably because some services can't be restarted safely. Currently =E2=80=98guix system reconfigure=E2=80=99 (specifically =E2=80=98upgrade-shepherd-services=E2=80=99) reloads and starts all service= s that are currently stopped, on the grounds that it would not be safe/desirable to simply stop any running service. > Would that be why we need a 'reload/reconfigure/upgrade' for them? =E2=80=98upgrade-shepherd-services=E2=80=99 could check whether a service h= as an =E2=80=98upgrade=E2=80=99 action. If it does, it could call that action un= conditionally since that action would semantically have the same effect has stop/unload/load/start, except that it does that =E2=80=9Clive=E2=80=9D, wi= thout stopping anything. >> Regarding nginx: >> >> + (stop (nginx-action "-s" "stop")) >> + (reload (nginx-action "-s" "reload")))))))) >> >> Is this of any use in practice? The nginx command line is something >> like: >> >> /gnu/store/74kz9m850ycxpzkg6dvn9wbd3xjkwwrb-nginx-1.12.0/sbin/nginx -c= /gnu/store/5w11ahw113fndvab3xmwcjzs2rw56sbh-nginx-config/bayfront.conf -p = /var/run/nginx >> >> and the configuration file in /gnu/store is immutable, so =E2=80=9Cnginx= -s >> reload=E2=80=9D does nothing. > > Actually, my goal was to use this after a certificate renewal. There > was going to be other patches on the certbot service as well :) And > after a certificate renewal, the names of the certificates don't change > (AFAIK they are still in /etc). Indeed. > So I think it would work. But indeed, I didn't think about the main > configuration file :/ Yeah. Sorry for dropping a fly in the ointment. :-/ >> If the action took an argument, we could do: >> >> herd reconfigure nginx /gnu/store/=E2=80=A6-new-config.conf >> >> which would translate to: >> >> nginx -s reload -c /gnu/store/=E2=80=A6-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=E2=80=99t clear. Action can take arguments; most don=E2=80= =99t, but some do (like =E2=80=98herd start cow-store /mnt=E2=80=99 when installing GuixSD= .) What I=E2=80=99m 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 =E2=80=9Cnginx -s reload -c =E2=80=A6=E2=80=9D and so on. The =E2=80=98upgrade-shepherd-services=E2=80=99 procedure would automatical= ly 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 =E2=80=98upgrade-arguments=E2=80=99 field to that would = return the arguments to pass to the upgrade action. Does that make sense? > Anyway, I think the argument should be optional, so that if there are > none, the current configuration file is used. That will be useful for > certificates anyway, or for other kinds of configuration files that > aren't in the store. We could do that too. My thought was that the primary consumer of this action would be =E2=80=98guix system reconfigure=E2=80=99 and not the user. Thanks, Ludo=E2=80=99.