Hello!
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (7 lines)
> Hi!>> At the Shepherd level, there’s no notion of service extension.> Normally, after reconfiguring, “herd restart guix-daemon” (really> “restart”, not “stop” + “start”) should start the new service, which> doesn’t have all these ‘--chroot-directory’ options.
FTR, I had used 'guix deploy' and issued 'sudo herd restart guix-daemon'on the remote after it completed successfully. Why should stop + startbe different than restart though? That seems counter-intuitive.
Toggle quote (7 lines)
> Note that the guix-daemon process you should seems to be a child process> (presumably because there was still a client running when you restarted> the service), not the main guix-daemon process.>> You should check the command line of the main process, the one returned> by “herd status guix-daemon”.
You are right that this process has the correct arguments:
$ sudo herd status guix-daemonStatus of guix-daemon: It is started. Running value is 25628. It is enabled. Provides (guix-daemon). Requires (user-processes). Conflicts with (). Will be respawned.
$ cat /proc/25628/cmdline/gnu/store/rqif4yxa6ny4nxrdq6whnva2r089jm0c-guix-1.2.0-13.a53f711/bin/guix-daemon--build-users-groupguixbuild--max-silent-time0--timeout0--log-compressionnone--discover=no--substitute-urlshttps://ci.guix.gnu.org--max-jobs=20
Some of the other process were apparently caused by 'guix environment' shells still running in screen; I've terminated them allnow and ran 'sudo herd stop guix-daemon'; surprisingly I still had tworemaining guix-daemon processes that were launched manually for testingpurposes. That's on a Guix system with an uptime of 174 days andcounting :-).
Thank you for the answer and sorry for the noise! It works as designed.
Closing.
Maxim