Hi Robert, Robert Vollmert writes: > On 8. Aug 2019, at 18:40, Chris Marusich wrote: >> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes: >> >>> 'switch-to-system-generation' doesn't call out to >>> 'upgrade-shepherd-services'. I'm not sure if this was an intentional >>> decision or not >> >> It is intentional, but only because there is currently no way to call >> upgrade-shepherd-services when switching system generations. > > How does shepherd work on a non-guix system? Can’t be it be configured > like other daemons to read its configuration from a file, e.g. from > > /run/current-system/etc/shepherd.conf > > and be told via signal to reload its configuration from disk? Maybe! In the email thread I linked, Ludo talked about storing a description of the Shepherd services in the system generation for future reference. Maybe we could store it in a place like this, and maybe Shepherd already has mechanisms for reloading configurations like this. I don't intend to work on this because I need to focus on other things right now, but I would be happy if someone took up this work! > (I feel a bit cheated right now. This behaviour makes Guix System entirely > unsuitable for server use. It shouldn’t be advertised as supporting > transactional upgrades and rollbacks if those require a reboot.) I agree that Guix should update as many Shepherd services as it can when switching generations. However, I don't think it's inaccurate to say that Guix supports transactional upgrades and rollbacks. When you invoke "guix system switch-generation", the system profile symlink is flipped atomically, so you get an atomic update from one version of the system to another. Software running in the system never sees an inconsistent view of the system. Contrast this with nearly any other mutable GNU/Linux system, in which files are more or less sprayed into the existing file system with no guarantee of consistency or atomicity. -- Chris