bug#55898: jami service failing following 'guix deploy' update
Hi again, [...] > Perhaps services should allow specifying the minimum required Shepherd > version, which Shepherd could ensure is met before attempting to restart > a service, printing something like: > > 'Could not restart service X due to unmet Shepherd version requirement; > the service will continue unchanged until the next reboot' > > or something similar. > > I've re-titled the bug, as this isn't specific to our jami service. I've asked in #systemd about what a similar situation would happen in systemd-land, and here's what I've learned: 1. service units aren't reloaded automatically after new versions of them are installed -- this effectively prevent the breakage seen here (the jami service was reloaded and restarting manually it caused it to fail). 2. a savvy user can still opt to force the new service to be reloaded via 'systemctl daemon-reload'. In case the service update depends on new systemd features, systemd would need to be restarted itself, via 'systemctl daemon-reexec'. The later command is interesting, but its documented as a debugging tool [0]: daemon-reexec Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible. [0] https://www.freedesktop.org/software/systemd/man/systemctl.html# systemd folks told me it is not typically run in systemd package upgrade hooks, but perhaps some distribution do this (I don't know). So the situation is not very different in systemd vs shepherd, except that we more aggressively load the new service definitions, potentially leading to breakage. Thoughts? Maxim
bug#55898: jami service failing following 'guix deploy' update
retitle 55898 Services depending on new Shepherd features may fail until a reboot thanks Hi, Maxim Cournoyer writes: [...] > I'm suspecting that given the service makes use of Shepherd 0.9 > features, perhaps it fails loading and the error is reported erroneously > that way... a reboot would tell but I'm not in a position to do that at > this moment (remote machine). I confirm that following a reboot, the service runs normally. Perhaps services should allow specifying the minimum required Shepherd version, which Shepherd could ensure is met before attempting to restart a service, printing something like: 'Could not restart service X due to unmet Shepherd version requirement; the service will continue unchanged until the next reboot' or something similar. I've re-titled the bug, as this isn't specific to our jami service. Thanks! Maxim
bug#55898: jami service failing following 'guix deploy' update
retitle 55898 jami service fails to start following reconfigure thanks Hello, Maxim Cournoyer writes: > Hello Maxime, > > Maxime Devos writes: > >> Maxim Cournoyer schreef op za 11-06-2022 om 01:53 [-0400]: >>> I don't get it; how can the service runs fine in the instrumented VMs >>> the system tests use, and fail in my updated machine? Could it be a >>> fault in 'guix deploy'? >> >> Maybe the shepherd has the old (gnu build jami-service) module loaded >> and it doesn't know know to reload modules during reconfiguration? The module seems to be simply missing, according to: --8<---cut here---start->8--- $ guix gc -R /gnu/store/sq7krjjpwbkr3z573flbnvkml1574mn5-system | grep jami /gnu/store/vkgamffkm92l3xdzid42k4lcz6aqfj7i-ffmpeg-jami-4.4.2 /gnu/store/kk3dzx2xsa135d1i5jsjm8i787gbl56i-pjproject-jami-2.11-0.e1f389d /gnu/store/fyd7rmvzhhqbk1f08c4pl7ahhlfgig40-shepherd-jami.scm /gnu/store/kqiqnza4l0jawrs0mszymj8diaa2j97m-shepherd-file-system--home-jenkins-jami.scm /gnu/store/yp9awyfgiym32card9w5mds8id6d6d0l-shepherd-file-system--home-jenkins-jami-workspace.scm /gnu/store/xib9gc60a8bbff99cffh2x74gqpszf0i-shepherd-jami-dbus-session.scm /gnu/store/q00v0f7syc1b6phfq4gih8i9irnm862w-dbus-for-jami-1.12.20 /gnu/store/dqfply51lzqc5z697k98avigsv21qm8q-libjami-20211223.2.37be4c3 /gnu/store/5w1zqbwagkhavqs7xjbzb8m7j978dcwj-shepherd-file-system--var-cache-jami.scm /gnu/store/njrxi4apky4ckb2py9qz0ciz0b92smrd-shepherd-jami.go /gnu/store/kciz8nady3rc5jd9j67bmlzyn622j5md-shepherd-file-system--home-jenkins-jami.go /gnu/store/ddxa8yxqh1c3h6iax2x24wj0lfxrx8c6-shepherd-file-system--home-jenkins-jami-workspace.go /gnu/store/d54hhmd90h7q4qmnb3q6ngsdp9457r80-shepherd-jami-dbus-session.go /gnu/store/59lizyj4miag5if9ylhk383qr1qbxw1h-shepherd-file-system--var-cache-jami.go --8<---cut here---end--->8--- After a 'guix system reconfigure' that successfully changed /run/current-system. I was expecting the module should have been pulled in the closure via the encapsulating: --8<---cut here---start->8--- (with-extensions (list guile-packrat ;used by guile-ac-d-bus guile-ac-d-bus ;; Fibers is needed to provide the non-blocking ;; variant of the 'sleep' procedure. guile-fibers) (with-imported-modules (source-module-closure '((gnu build dbus-service) (gnu build jami-service) (gnu build shepherd) (gnu system file-systems))) --8<---cut here---end--->8--- in (gnu services telephony) around line 312. Thoughts? Maxim
bug#55898: jami service failing following 'guix deploy' update
Hello Maxime, Maxime Devos writes: > Maxim Cournoyer schreef op za 11-06-2022 om 01:53 [-0400]: >> I don't get it; how can the service runs fine in the instrumented VMs >> the system tests use, and fail in my updated machine? Could it be a >> fault in 'guix deploy'? > > Maybe the shepherd has the old (gnu build jami-service) module loaded > and it doesn't know know to reload modules during reconfiguration? If true, that would indeed explain it. Thanks, Maxim
bug#55898: jami service failing following 'guix deploy' update
Maxim Cournoyer schreef op za 11-06-2022 om 01:53 [-0400]: > I don't get it; how can the service runs fine in the instrumented VMs > the system tests use, and fail in my updated machine? Could it be a > fault in 'guix deploy'? Maybe the shepherd has the old (gnu build jami-service) module loaded and it doesn't know know to reload modules during reconfiguration? Greetings, Maxime. signature.asc Description: This is a digitally signed message part
bug#55898: jami service failing following 'guix deploy' update
Hello Guix! After having fixed the tests of the jami-service-type and pushed the fix as 85b4dabd94d53f8179f31a42046cd83fc3a352fc, I was confident it would work, but my freshly 'guix deploy'ed machine says otherwise: --8<---cut here---start->8--- $ sudo herd stop jami $ sudo herd start jami Service jami-dbus-session has been started. herd: exception caught while executing 'start' on service 'jami': Unbound variable: jami-service-available? $ guix system describe Generation 141 Jun 11 2022 01:38:12(current) file name: /var/guix/profiles/system-141-link canonical file name: /gnu/store/vx9sd4vb2yfv0zhycd461m9wfvgzclsp-system label: GNU with Linux-Libre 5.17.14 bootloader: grub-efi root device: label: "btrfs-pool-1" kernel: /gnu/store/zf4062hz23485dp1xr8w6zbk2m8igpsk-linux-libre-5.17.14/bzImage configuration file: /gnu/store/n2wqba6npybjd8i730cpi9qc61p16jkr-configuration.scm --8<---cut here---end--->8--- I don't get it; how can the service runs fine in the instrumented VMs the system tests use, and fail in my updated machine? Could it be a fault in 'guix deploy'? To be investigated... Thanks, Maxim
