Hi Guix, Another bug/experience report for you:
============================================================================================================ The unprivileged guix-daemon.service cannot be restarted successfully if a Guix System container is running. ============================================================================================================ I use these kinds of containers extensively for deploying web applications, GeoServers, job servers, and microservices at work. However, since I upgraded some of my Ubuntu VMs to Guix 1.5.0, the new unprivileged `guix-daemon.service` gets into a broken state if I ever restart it while I have a Guix System container running on the same VM. This is because this new `guix-daemon.service` depends on another new service called `gnu-store.mount`. This dependency is stopped and restarted automatically around restarts to the `guix-daemon.service`, and its purpose appears to be providing a read/write mount of /gnu/store to the guix-daemon user's unprivileged user namespace. If a Guix System container is running when you attempt to restart `guix-daemon.service`, the `gnu-store.mount` service will fail to unmount and remount /gnu/store into this namespace because it will complain that the /gnu/store is currently busy. As a result, `guix-daemon.service` will restart itself, but it ends up only having read access to the /gnu/store. Thus, subsequent guix commands that attempt to build software or add packages, containers, derivations, etc. to the /gnu/store will fail to run. This bit me recently because I had a Jenkins job that would run `guix pull` as root to update its Guix revision before restarting `guix-daemon.service`. (And yes, I know that root's Guix revision is only for the guix-daemon on a foreign distro. All of my normal Guix commands are run through unprivileged users with their own Guix revisions created by `guix pull`, `guix time-machine`, and so on.) Because I keep long-running Guix System containers on these VMs, this `guix-daemon.service` restart broke my Guix build daemon and prevented any further Guix commands from working until I discovered the problem, stopped the containers, resatarted `gnu-store.mount`, and then finally restarted `guix-daemon.service` again. I have since updated my Jenkins jobs to always stop all Guix System containers to release their hold on the /gnu/store before restarting `guix-daemon.service`, and this has gotten my servers operational again. However, I wanted to report this to the list in case anyone else is running into this issue. I don't know if the Guix development team can do anything to alleviate this issue, even if it is just to make the `guix-daemon.service` emit big hairy error messages whenever someone tries to restart it while a container is running since they are in the process of breaking their Guix build daemon. Thanks, Gary -- GPG Key ID: C4FBEDBD Use `gpg --search-keys [email protected]' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Why is HTML email a security nightmare? See https://useplaintext.email/ Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
