'guix system switch-generation' does not reload Shepherd services

OpenSubmitted by Robert Vollmert.
Details
7 participants
  • Brice Waegeneire
  • Chris Marusich
  • Christopher Lemmer Webber
  • Ludovic Courtès
  • Mark H Weaver
  • Robert Vollmert
  • Jakob L. Kreuze
Owner
unassigned
Severity
important
Merged with
R
R
Robert Vollmert wrote on 30 Jul 2019 12:00
guix system switch-generation doesn't
(address . bug-guix@gnu.org)
7BE8190F-A8E9-454E-8F37-FBFE42FBDE10@vllmrt.net
What I see:
1. edit ~/pzprnode/pzprnode
rob@garp ~/pzprnode$ git diff
Toggle diff (57 lines)diff --git a/pzprnode b/pzprnodeindex 612e6a8..d8ef0ea 100755--- a/pzprnode+++ b/pzprnode@@ -190,5 +190,6 @@ const server = http.createServer((req, res) => { }); server.listen(port, hostname, () => {+ console.log("updated version"); console.log(`Server running at http://${hostname}:${port}/`); });
2. sudo guix system reconfigure -L ~/garp-config ~/garp-config/config.scm3. sudo herd restart pzprnode4. less /var/log/messages
Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been stopped. Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been started. Jul 30 11:46:58 localhost pzprnode[4954]: updated version Jul 30 11:46:58 localhost pzprnode[4954]: Server running at http://127.0.0.1:3456/
5. sudo guix system list-generations
Generation 151 Jul 30 2019 10:37:06 file name: /var/guix/profiles/system-151-link canonical file name: /gnu/store/jis33accsfpa068aps0a9mrycmjzfm4m-system label: GNU with Linux-Libre 5.2.1 bootloader: grub root device: label: "guix-root" kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImageGeneration 152 Jul 30 2019 11:43:13 (current) file name: /var/guix/profiles/system-152-link canonical file name: /gnu/store/3z3wmaj0399kihqc372y91nzcjxc1myl-system label: GNU with Linux-Libre 5.2.1 bootloader: grub root device: label: "guix-root" kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage
6. sudo guix system switch-generation 151
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%The following derivation will be built: /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drvbuilding /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv...switched from generation 152 to 151
7. sudo herd restart pzprnode8. less /var/log/messages
Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been stopped. Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been started. Jul 30 11:48:03 localhost pzprnode[4994]: updated version Jul 30 11:48:03 localhost pzprnode[4994]: Server running at http://127.0.0.1:3456/
The line with “updated version” should not be there.
Presumably, this is due to switch-generations not calling upgrade-shepherd-services.
J
J
Jakob L. Kreuze wrote on 30 Jul 2019 18:16
(name . Robert Vollmert)(address . rob@vllmrt.net)(address . 36855@debbugs.gnu.org)
87zhkvv6pm.fsf@sdf.lonestar.org
Hi Robert,
Robert Vollmert <rob@vllmrt.net> writes:
Toggle quote (5 lines)> The line with “updated version” should not be there.>> Presumably, this is due to switch-generations not calling> upgrade-shepherd-services.
I can confirm that 'switch-to-system-generation', the procedure thatcarries out 'guix system switch-generation', neither invokes'upgrade-shepherd-services' nor runs that system's activation script.
I'd be interested to hear from others who have worked on 'guix system'as to whether or not it would be a good idea to perform the effectfulparts of a system activation for 'switch-generation'. I haven't yetpondered upon the implications.
Regards,Jakob
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl1AbUUACgkQ9Qb9Fp2P2VoqLQ//e5V6M06WzlfrTAjUQ7aFELkjPKyuhTGQpPlNNacYB5YIFBehWIutpL62S0pMMEcdCLbiY60YWV61U8FOuUJCTn2mKkSCFNFdG6oqJIsVptLpU+cGLIRsBy3xrjPdBtAzE/gyW/PixoN/OorBNpFuvRNtn2LZG5MyqqIZpgK/S7iaSTF4E79Lc85J+yUdzz2xRioRO1xPPYDItk5wQzI/PYnoUh8xbm74Ie+WhF0ytq85E/VaptrO38LbERJW0WlXcfCHSZqq3b3LZ8+3N/YYjoxbJt4hIpwBNh0xlDDCLhGc7PssJXsUaUoj8f4BX1m7Tt6IvpotvTb/xaMm9lRJzTw7WOkDRNkWvAFEJTZrSNYZrwS9djaq+woKrxXG8LGS2ah7lCeNqBKQtihkmOSOGr6yrtYOgSRaOy2m5D0MI+G0h9VR+aguVX10TEcCOn9xYmV5sIVqx6Ns6+86XJLcujSdQycbE+uKVgn4JMMpzHFRf0aultphjjpJO6Jm/FjCf9u3SZJsYwPRwvlAul0/seLEWiN/rErO/0fl9AYhysFiHL5hNmFR1ySWtcJuttQjmHbhS7VPFnd4B8bzasIXooKxWJpEqO5yoCoD+L6OZW2spWnMZuD6+jQnlgyfIXXoyfZsHMkUfUgKwGoErK6tKHVabEwOyuDGqhBTRD+WZs8==NiIU-----END PGP SIGNATURE-----
R
R
Robert Vollmert wrote on 6 Aug 2019 23:21
Re: guix system switch-generation doesn't
(address . bug-guix@gnu.org)(name . GitHub Developer Support)(address . developer@githubsupport.com)
3F889811-B4FA-415F-B4C0-7994DD00A968@vllmrt.net
Could we get some input on this bug?
Maybe I’m misunderstanding something, but it seems that a core guixfeature (atomic rollbacks) doesn’t work…
Toggle quote (65 lines)> On 30. Jul 2019, at 12:00, Robert Vollmert <rob@vllmrt.net> wrote:> > What I see:> > 1. edit ~/pzprnode/pzprnode> > rob@garp ~/pzprnode$ git diff> diff --git a/pzprnode b/pzprnode> index 612e6a8..d8ef0ea 100755> --- a/pzprnode> +++ b/pzprnode> @@ -190,5 +190,6 @@ const server = http.createServer((req, res) => {> });> > server.listen(port, hostname, () => {> + console.log("updated version");> console.log(`Server running at http://${hostname}:${port}/`);> });> > 2. sudo guix system reconfigure -L ~/garp-config ~/garp-config/config.scm> 3. sudo herd restart pzprnode> 4. less /var/log/messages> > Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been stopped. > Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been started. > Jul 30 11:46:58 localhost pzprnode[4954]: updated version > Jul 30 11:46:58 localhost pzprnode[4954]: Server running at http://127.0.0.1:3456/ > > 5. sudo guix system list-generations> > Generation 151 Jul 30 2019 10:37:06> file name: /var/guix/profiles/system-151-link> canonical file name: /gnu/store/jis33accsfpa068aps0a9mrycmjzfm4m-system> label: GNU with Linux-Libre 5.2.1> bootloader: grub> root device: label: "guix-root"> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage> Generation 152 Jul 30 2019 11:43:13 (current)> file name: /var/guix/profiles/system-152-link> canonical file name: /gnu/store/3z3wmaj0399kihqc372y91nzcjxc1myl-system> label: GNU with Linux-Libre 5.2.1> bootloader: grub> root device: label: "guix-root"> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage> > 6. sudo guix system switch-generation 151> > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%> The following derivation will be built:> /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv> building /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv...> switched from generation 152 to 151> > 7. sudo herd restart pzprnode> 8. less /var/log/messages> > Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been stopped. > Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been started. > Jul 30 11:48:03 localhost pzprnode[4994]: updated version > Jul 30 11:48:03 localhost pzprnode[4994]: Server running at http://127.0.0.1:3456/ > > The line with “updated version” should not be there.> > Presumably, this is due to switch-generations not calling upgrade-shepherd-services.>
R
R
Robert Vollmert wrote on 6 Aug 2019 23:25
(address . 36855@debbugs.gnu.org)(address . guix-devel@gnu.org)
A3C3B87A-1B74-4983-A8EA-7281E3103567@vllmrt.net
Could we get some input on this bug?
Maybe I’m misunderstanding something, but it seems that a core guixfeature (atomic rollbacks) doesn’t work…
Toggle quote (65 lines)> On 30. Jul 2019, at 12:00, Robert Vollmert <rob@vllmrt.net> wrote:> > What I see:> > 1. edit ~/pzprnode/pzprnode> > rob@garp ~/pzprnode$ git diff> diff --git a/pzprnode b/pzprnode> index 612e6a8..d8ef0ea 100755> --- a/pzprnode> +++ b/pzprnode> @@ -190,5 +190,6 @@ const server = http.createServer((req, res) => {> });> > server.listen(port, hostname, () => {> + console.log("updated version");> console.log(`Server running at http://${hostname}:${port}/`);> });> > 2. sudo guix system reconfigure -L ~/garp-config ~/garp-config/config.scm> 3. sudo herd restart pzprnode> 4. less /var/log/messages> > Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been stopped. > Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been started. > Jul 30 11:46:58 localhost pzprnode[4954]: updated version > Jul 30 11:46:58 localhost pzprnode[4954]: Server running at http://127.0.0.1:3456/ > > 5. sudo guix system list-generations> > Generation 151 Jul 30 2019 10:37:06> file name: /var/guix/profiles/system-151-link> canonical file name: /gnu/store/jis33accsfpa068aps0a9mrycmjzfm4m-system> label: GNU with Linux-Libre 5.2.1> bootloader: grub> root device: label: "guix-root"> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage> Generation 152 Jul 30 2019 11:43:13 (current)> file name: /var/guix/profiles/system-152-link> canonical file name: /gnu/store/3z3wmaj0399kihqc372y91nzcjxc1myl-system> label: GNU with Linux-Libre 5.2.1> bootloader: grub> root device: label: "guix-root"> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage> > 6. sudo guix system switch-generation 151> > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%> The following derivation will be built:> /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv> building /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv...> switched from generation 152 to 151> > 7. sudo herd restart pzprnode> 8. less /var/log/messages> > Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been stopped. > Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been started. > Jul 30 11:48:03 localhost pzprnode[4994]: updated version > Jul 30 11:48:03 localhost pzprnode[4994]: Server running at http://127.0.0.1:3456/ > > The line with “updated version” should not be there.> > Presumably, this is due to switch-generations not calling upgrade-shepherd-services.>
C
C
Christopher Lemmer Webber wrote on 7 Aug 2019 21:37
Re: bug#36855: guix system switch-generation doesn't
(address . bug-guix@gnu.org)
87zhkkojfv.fsf@dustycloud.org
Could you look at bug #36878 and commit 1db6f137d... as of latestmaster, is this fixed?
Robert Vollmert writes:
Toggle quote (70 lines)> Could we get some input on this bug?>> Maybe I’m misunderstanding something, but it seems that a core guix> feature (atomic rollbacks) doesn’t work…>>> On 30. Jul 2019, at 12:00, Robert Vollmert <rob@vllmrt.net> wrote:>> >> What I see:>> >> 1. edit ~/pzprnode/pzprnode>> >> rob@garp ~/pzprnode$ git diff>> diff --git a/pzprnode b/pzprnode>> index 612e6a8..d8ef0ea 100755>> --- a/pzprnode>> +++ b/pzprnode>> @@ -190,5 +190,6 @@ const server = http.createServer((req, res) => {>> });>> >> server.listen(port, hostname, () => {>> + console.log("updated version");>> console.log(`Server running at http://${hostname}:${port}/`);>> });>> >> 2. sudo guix system reconfigure -L ~/garp-config ~/garp-config/config.scm>> 3. sudo herd restart pzprnode>> 4. less /var/log/messages>> >> Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been stopped. >> Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been started. >> Jul 30 11:46:58 localhost pzprnode[4954]: updated version >> Jul 30 11:46:58 localhost pzprnode[4954]: Server running at http://127.0.0.1:3456/ >> >> 5. sudo guix system list-generations>> >> Generation 151 Jul 30 2019 10:37:06>> file name: /var/guix/profiles/system-151-link>> canonical file name: /gnu/store/jis33accsfpa068aps0a9mrycmjzfm4m-system>> label: GNU with Linux-Libre 5.2.1>> bootloader: grub>> root device: label: "guix-root">> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage>> Generation 152 Jul 30 2019 11:43:13 (current)>> file name: /var/guix/profiles/system-152-link>> canonical file name: /gnu/store/3z3wmaj0399kihqc372y91nzcjxc1myl-system>> label: GNU with Linux-Libre 5.2.1>> bootloader: grub>> root device: label: "guix-root">> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage>> >> 6. sudo guix system switch-generation 151>> >> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%>> The following derivation will be built:>> /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv>> building /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv...>> switched from generation 152 to 151>> >> 7. sudo herd restart pzprnode>> 8. less /var/log/messages>> >> Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been stopped. >> Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been started. >> Jul 30 11:48:03 localhost pzprnode[4994]: updated version >> Jul 30 11:48:03 localhost pzprnode[4994]: Server running at http://127.0.0.1:3456/ >> >> The line with “updated version” should not be there.>> >> Presumably, this is due to switch-generations not calling upgrade-shepherd-services.>>
J
J
Jakob L. Kreuze wrote on 7 Aug 2019 21:57
(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)
877e7on3zd.fsf@sdf.lonestar.org
Hi Chris,
Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
Toggle quote (3 lines)> Could you look at bug #36878 and commit 1db6f137d... as of latest> master, is this fixed?
Unfortunately, I don't think that 1db6f137d fixes this. The issue is abit more structural as 'switch-to-system-generation' doesn't call out to'upgrade-shepherd-services'. I'm not sure if this was an intentionaldecision or not (perhaps we can ask Ludo when he returns).
Regards,Jakob
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl1LLRYACgkQ9Qb9Fp2P2Vph4A//cUuLKGk+70b9MEa5VKXtTqIcSN4duoJaZw/1/3PQxzE1k5vwBFTP9SWcyPH+Ma1YOaiPYihPtkGZZpuEpsJAaXi+5bMBTeDVv41SameHN6qp85ftUp9utcVmvRzMDfGL7PKbcxlMQZFSTMUrak3fXxAMFg09oVemG2jUOlT0jt6CJSi/gDceV8aDekGz9W/kw5z4tYgwHEooyUwg36tZiJ9bmPZMqWykMJatXCv5Y3xfniAC2YwHhCjdooahYY1YQd6RqRXzpo6LaJYsue6lq1fGdvsGQQFqZElqZHhEshpHgfcD+y7Z63PP9MDmj+CAwsVT4NclYIFajEJGVXO/jWCqTz7dgu/r+QBq6OcrE4GCKqEyd3OpUSPMAh06+42PjVk6P5jwFgvjLOd5uoqlpdJEIWwjnYk7lElKEoNIVW6ZAsZ9KSLEKhZ8S7+0dyrWtVymTBv4hCR4ozMaA8pNV+7Yy8h8DWzihKNIepLdbCfg+da5bAmQjeZ1wViarkiJuCJSuU/YPl/gwWCjpCf9FlBP/NuZrmzMJcz6HbQlCJQGGkLtxXrbB7iSfB3DrtSMShJMaGfDBTpJk4UYTuJHdwwWlavJYTXRChuuoAOp9pbtLz/1SX/j1MGS/lZ8VAyVaK/Dj2sryI7xOJBebAYzf+QVJ7/XRWK/X2sYppxt0OM==qQfH-----END PGP SIGNATURE-----
C
C
Chris Marusich wrote on 8 Aug 2019 18:40
(name . Jakob L. Kreuze)(address . zerodaysfordays@sdf.lonestar.org)
87h86ry5j5.fsf@gmail.com
Hi Jakob,
zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:
Toggle quote (4 lines)> '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 callupgrade-shepherd-services when switching system generations.
Consider the procedure upgrade-shepherd-services: you must pass it an<operating-system> record. When you are flipping from one generation toanother, how do you get the <operating-system> record that was used forthe generation you're switching to? Guix doesn't currently store theoperating system configuration file or its <operating-system> recordanywhere, so we can't call upgrade-shepherd-services.
This was discussed in 2016 and we agreed we need to persist someinformation to enable us to handle Shepherd services correctly. This iswhat Ludo suggested at the time:
https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00173.html
"Maybe we could store in the system output (result of ‘guix systembuild’) an sexp representation of (part of) our <shepherd-service>records:
(shepherd-service (provisions (x y z)) (requirements (a b c)) (start-script "/gnu/store/…-start-foo.scm") (stop-script "/gnu/store/…-stop-foo.scm") …)
Then ‘upgrade-shepherd-services’ could start from this simplifiedrepresentation instead of using the full-blown <shepherd-service>objects, and thus could work both when instantiating a new generationand when rolling back."
Until that happens, you'll always have to reboot to complete theswitch.
FYI, last I checked (about 3 years ago), in NixOS they took a slightlydifferent approach: instead of storing state describing the previoussystem generation and relying on the current system's logic to correctlyparse it and use it to revert the system to a prior configuration, theyjust dump everything into a self-contained script that knows how toupdate the entire system to one specific configuration. That approachis nice in some ways because switching generations is dead simple - youjust run the switching script belonging to the generation you want toswitch to - but it also has downsides.
For example, if the target generation is old enough compared to thecurrent system, then the target generation's old switching script mightnot understand how to deal with the current system correctly. Instead,if you only store the bare minimum of state required to take the rightactions, and you implement the meat of the logic in the current Guixinstallation, you are more likely to be able to switch generations evento very old ones where the world was very different, since the currentGuix can be taught how to deal gracefully with the old world. But itseems more complicated. It's all about trade-offs.
That said, I've never gone back to implement this. If you want to giveit a try, you're more than welcome to do so!
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAl1MUH4ACgkQ3UCaFdgiRp3y+hAAsKd93p6eAbVyYpZ/RFPBv47+yxJ3Lu0vmYNzch9MeZtlpNpyhQLeLvtw7qUCxxB9Lht1gveqRnuqByXjV8aIHXpflMdoV8TF0nfEShFNbYGaN2ZDgKURNxiz9Cpa8Oso7OsQ33HhJVSIn8vK00yZXH7bRyoGZeWrHW/G4mUKVv+R05qcBx9SmJY8Aa94WEi5ei5XQYj43YHHctb/W91b7/eNoXQf61pdBVFVDUc/Q/5w3eG6p5Ywq7OTDAaW5klERz5xqanx78KxBblDIh3TjQgo28MCeVJMAeHThOMSKrh2v0iBy/ORaVeDckzIsdmviVutbBYjVOdphn2uvAjqXc1zFiQ1ypFB8P6+qOZuxQFJr/sGIvFtKZ1Mfqz027obBpIa8iVWBYQg5xgmoL/qkEiw8x5/aVVbxm2P7cpmh6pNn3UV65uZ5wM/sGabloJcYwR45S/IAdZ69xdbqeltR3JPaFiS5Yj1kDvXzXewv/gxypGaVGZn2py6119Db0JqB5nlZU6kdpGHOriNPy1kRLjb77B7JFprBhESfDmNZToF0/emDPpJyOkAQ9fvNhsjuqkOWSrbjDMG7HvV9MWsvVBPTnbDgO1Oq7GJdXl1W0dyzsxeWSgCb18LVbj7WhWYqIVOfeZ5jayscze9tD5ZE6UI50Gx1MHDCwWrUd7GuHA==iNTf-----END PGP SIGNATURE-----
R
R
Robert Vollmert wrote on 8 Aug 2019 19:03
(name . Chris Marusich)(address . cmmarusich@gmail.com)
51A8B412-1AE3-4464-8146-DE8B19B7C4DF@vllmrt.net
On 8. Aug 2019, at 18:40, Chris Marusich <cmmarusich@gmail.com> wrote:
Toggle quote (9 lines)> 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 configuredlike 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?

(I feel a bit cheated right now. This behaviour makes Guix System entirelyunsuitable for server use. It shouldn’t be advertised as supportingtransactional upgrades and rollbacks if those require a reboot.)
C
C
Chris Marusich wrote on 9 Aug 2019 09:35
(name . Robert Vollmert)(address . rob@vllmrt.net)
87o90yvlin.fsf@gmail.com
Hi Robert,
Robert Vollmert <rob@vllmrt.net> writes:
Toggle quote (17 lines)> On 8. Aug 2019, at 18:40, Chris Marusich <cmmarusich@gmail.com> 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 adescription of the Shepherd services in the system generation for futurereference. Maybe we could store it in a place like this, and maybeShepherd already has mechanisms for reloading configurations like this.I don't intend to work on this because I need to focus on other thingsright now, but I would be happy if someone took up this work!
Toggle quote (4 lines)> (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 whenswitching generations. However, I don't think it's inaccurate to saythat Guix supports transactional upgrades and rollbacks. When youinvoke "guix system switch-generation", the system profile symlink isflipped atomically, so you get an atomic update from one version of thesystem to another. Software running in the system never sees aninconsistent view of the system. Contrast this with nearly any othermutable GNU/Linux system, in which files are more or less sprayed intothe existing file system with no guarantee of consistency or atomicity.
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAl1NIlAACgkQ3UCaFdgiRp2VIw//US1/6CiS04hRQjoDqQ84bx59a3iownqkYyiAL/94IUUetS4ZNSg5nQ4APir0iD/3vJEsXLnBzKwH7AcC8mRYI3AUviv+AT7LYKuM95UVOeqp1iuUKlzCQRXlszOwI19vOJKFHrpjPEcwev1/c5Y2hYMW2rRTuajfvkeS2QNiLzNODMMjkksDcHVTtezSf72AtLL74+qXsmDidJpLYXbJ60EK4hFEztJcJLRekN5B0tT06W9qpsRCtNoBO8j8BHLDFvQXj9+2fj1TXGLYnUu0UbmgxoAaykCVIB9RxcWCfoq/ZHxT2SxUiHBG9HxBKaRnCdXHcGdHiH9vuVjg7vFTBkYHBTFs9Z8rhEzWhoCcXVozbGEY33OUPcdn0aNqWsQX4er5ewWiDK6Rkw1XrCpl/Jxe+BKLjTIO/UuWAHhpF87HcqznddzjuerpW6zNXmo0HnweObv/VjWOyf3u+9kwMBRjxXO1FOSZD5D7DAAZewfKE/9CVSbrsjn5yubVoCB/Yb4ZPJ33w3oXQVHnxL4yrbv3DMdQYNNLkdfQc9n6m3d8nnpsaHTkEmaY9UdLCpeKN75QVyh66comhZbmkNQ6I7vGypqTDVo12/09aF7YLCDC9AiKYvZ4TYD9dq7znOudwA72iyxRSM+JRPDmvXXNIr9ypSHjBrPjX6vY8LX882M==fHHl-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 26 Aug 2019 12:07
(name . Chris Marusich)(address . cmmarusich@gmail.com)
874l241bq6.fsf@gnu.org
Hey Chris & Jakob,
Chris Marusich <cmmarusich@gmail.com> skribis:
Toggle quote (9 lines)> 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.
[...]
Toggle quote (10 lines)> FYI, last I checked (about 3 years ago), in NixOS they took a slightly> different approach: instead of storing state describing the previous> system generation and relying on the current system's logic to correctly> parse it and use it to revert the system to a prior configuration, they> just dump everything into a self-contained script that knows how to> update the entire system to one specific configuration. That approach> is nice in some ways because switching generations is dead simple - you> just run the switching script belonging to the generation you want to> switch to - but it also has downsides.
Jakob, now that we generate scripts for the effectful bits of systemreconfiguration (one of these bits being service upgrades), couldn’t wetake it one step further and store those scripts in the “system”derivation so we can run them eventually, notably upon‘switch-generation’?
Toggle quote (10 lines)> For example, if the target generation is old enough compared to the> current system, then the target generation's old switching script might> not understand how to deal with the current system correctly. Instead,> if you only store the bare minimum of state required to take the right> actions, and you implement the meat of the logic in the current Guix> installation, you are more likely to be able to switch generations even> to very old ones where the world was very different, since the current> Guix can be taught how to deal gracefully with the old world. But it> seems more complicated. It's all about trade-offs.
Indeed. The important thing to me is that from the GRUB menu you canreally switch to any generation. I’ve actually never used‘switch-generations’ on my laptop, but technically, I feel like storingthe “switch-to-system” script would be the easiest way.
Thanks,Ludo’.
M
M
Mark H Weaver wrote on 26 Aug 2019 20:51
(name . Ludovic Courtès)(address . ludo@gnu.org)
87woezoj3p.fsf@netris.org
Hi,
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (6 lines)> Jakob, now that we generate scripts for the effectful bits of system> reconfiguration (one of these bits being service upgrades), couldn’t we> take it one step further and store those scripts in the “system”> derivation so we can run them eventually, notably upon> ‘switch-generation’?
As a bonus, this approach might solve another issue I've observed: on myGuix system, where I build everything locally, several derivations arebuilt *during* activation. Based on the terminal output, I get theimpression that the system is compiling things while the system in anintermediate state, when some of the activation steps have been done,but not all of them.
As I recall, the derivations built during activation are limited tocompiled modules for Guile, but it still sometimes takes on the order ofa minute or two on my laptop to complete the "activating system" steps.This seems suboptimal.
The next time I update my system, I'll try to remember to keep atranscript of this, so that I can be more specific.
Best, Mark
M
M
Mark H Weaver wrote on 28 Aug 2019 02:34
(name . Ludovic Courtès)(address . ludo@gnu.org)
87tva2m8ki.fsf@netris.org
Hello again,
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (23 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> Jakob, now that we generate scripts for the effectful bits of system>> reconfiguration (one of these bits being service upgrades), couldn’t we>> take it one step further and store those scripts in the “system”>> derivation so we can run them eventually, notably upon>> ‘switch-generation’?>> As a bonus, this approach might solve another issue I've observed: on my> Guix system, where I build everything locally, several derivations are> built *during* activation. Based on the terminal output, I get the> impression that the system is compiling things while the system in an> intermediate state, when some of the activation steps have been done,> but not all of them.>> As I recall, the derivations built during activation are limited to> compiled modules for Guile, but it still sometimes takes on the order of> a minute or two on my laptop to complete the "activating system" steps.> This seems suboptimal.>> The next time I update my system, I'll try to remember to keep a> transcript of this, so that I can be more specific.
Here's a transcript:
Toggle snippet (19 lines)activating system...building /gnu/store/fbp6bbxw9cf617fmk57sddrz7zfsfw5p-module-import-compiled.drv...building /gnu/store/wfi6hnr9ggal0s1d32xx5wbl5k5wqlvx-switch-to-system.scm.drv...making '/gnu/store/mjzk53ia3bajn08lscpyzz5apcw3r70g-system' the current system...setting up setuid programs in '/run/setuid-programs'...populating /etc from /gnu/store/l7r1has973n26hfqrs6vxbi94xzgh360-etc...building /gnu/store/h2fqcxv3xx14lkdhyphm3lawkayw7sdl-module-import-compiled.drv...building /gnu/store/dar9smjyxmri6v6cchnmp5mpyiimyx64-install-bootloader.scm.drv...guix system: bootloader successfully installed on '/dev/sda'building /gnu/store/vkk3h5p799lfpmf6msdhrzlq0wqvk3zq-module-import-compiled.drv...building /gnu/store/hn8sr8p13gg2mf379xawscabckp03fkb-upgrade-shepherd-services.scm.drv...shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?).guix system: warning: only 3.9% of free space available on /gnu/storehint: Consider deleting old profile generations and collecting garbage, along these lines:
guix gc --delete-generations=1m

Mark
J
J
Jakob L. Kreuze wrote on 28 Aug 2019 20:28
(name . Ludovic Courtès)(address . ludo@gnu.org)
8736hlp2js.fsf@sdf.lonestar.org
Hi Ludo,
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (6 lines)> Jakob, now that we generate scripts for the effectful bits of system> reconfiguration (one of these bits being service upgrades), couldn’t> we take it one step further and store those scripts in the “system”> derivation so we can run them eventually, notably upon> ‘switch-generation’?
We'd need to find a way of serializing at least the relationshipsbetween services, but I think it's possible (albeit quite involved). Ido really like the idea, though. That way, the system generation wouldfully encompass the desired state of the system.
Regards,Jakob
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl1mx9cACgkQ9Qb9Fp2P2Vr6ug/7BAHt99XLSlA1NNqfodZ7hW+jlTAmfM/RXEC9yWbccpHICaxvncwzqtTz1u6FaCNkz853Q4lCwh+xxNSHGD1IryxjjIXcosO2mQuqnujLjzHlQxmPMRMZTf0pwiYtDE1vZXPOuuamwJg2+ETSYq3XwRCUztTC1u7d2Z4Ss6fBNGbG6+sTNoLyccbjwdKk6phulg2HysKpzbJzxHWJ2G+sZ8xcOwXHuffEz4GGYGEj7SH7jhMTgYvdRHiAZGB16FQJ8UEupmmJ5XuC028G10RVUkBfLbkrKKAYLDuo14sqoGkPn+95s4ezwmxJJI5ODviO9dCkkOcTvnmQbRLMo2n8pLfRXo4JI5BDVvhRbP0IGX/GWStHFYH0pdrbGdfy+MIM7/lWDUH/cjXl+Md5biLBXpyxZ071sf8fZm0tmYJrB7iSpguLl2ROQWiQWkCe29JsMSNzACxmF4isnuy5ZTNr/2pp4xmUAVx7+xoy8ZamIAjGR1z0FSXBFp0IWgFNllBHNDN9Wn9xPZIU5cfDMvAmJq9Ifvp5HnpyJZa10E3b0+6ZM4cP3rC5jAY7vutgtwm2YIAqa2qQJlEa8wcxFRPm3yByrcE+UHidFnii0e/a0D4X2pL7igw6/tnRQxvXXNRUHOK+Ysno0kyOUYJTn6OTCrkdmhduPx/BmlaSw5QaK48==Mllt-----END PGP SIGNATURE-----
J
J
Jakob L. Kreuze wrote on 28 Aug 2019 20:33
(name . Mark H Weaver)(address . mhw@netris.org)
87y2zdnnrl.fsf@sdf.lonestar.org
Hi Mark,
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (40 lines)> Hello again,>> Mark H Weaver <mhw@netris.org> writes:>>> As a bonus, this approach might solve another issue I've observed: on my>> Guix system, where I build everything locally, several derivations are>> built *during* activation. Based on the terminal output, I get the>> impression that the system is compiling things while the system in an>> intermediate state, when some of the activation steps have been done,>> but not all of them.>>>> As I recall, the derivations built during activation are limited to>> compiled modules for Guile, but it still sometimes takes on the order of>> a minute or two on my laptop to complete the "activating system" steps.>> This seems suboptimal.>>>> The next time I update my system, I'll try to remember to keep a>> transcript of this, so that I can be more specific.>> Here's a transcript:>> activating system...> building /gnu/store/fbp6bbxw9cf617fmk57sddrz7zfsfw5p-module-import-compiled.drv...> building /gnu/store/wfi6hnr9ggal0s1d32xx5wbl5k5wqlvx-switch-to-system.scm.drv...> making '/gnu/store/mjzk53ia3bajn08lscpyzz5apcw3r70g-system' the current system...> setting up setuid programs in '/run/setuid-programs'...> populating /etc from /gnu/store/l7r1has973n26hfqrs6vxbi94xzgh360-etc...> building /gnu/store/h2fqcxv3xx14lkdhyphm3lawkayw7sdl-module-import-compiled.drv...> building /gnu/store/dar9smjyxmri6v6cchnmp5mpyiimyx64-install-bootloader.scm.drv...> guix system: bootloader successfully installed on '/dev/sda'> building /gnu/store/vkk3h5p799lfpmf6msdhrzlq0wqvk3zq-module-import-compiled.drv...> building /gnu/store/hn8sr8p13gg2mf379xawscabckp03fkb-upgrade-shepherd-services.scm.drv...> shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?).> guix system: warning: only 3.9% of free space available on /gnu/store> hint: Consider deleting old profile generations and collecting garbage, along these lines:>> guix gc --delete-generations=1m>> Mark
Thanks for the input; I wasn't aware that the activation process wastaking so long for some people. One of Ludovic's suggestions was tocreate a single derivation, rather than three, to speed up systemactivation. I'll look into this further.
Regards,Jakob
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl1myO4ACgkQ9Qb9Fp2P2Vo4AA/9FVJyp6OfbInjB/I0Ds27/CbzT3AO+EB4Oy0XYbQtowNhIcraLR0/yxRh9Zar+zosHG/WOtA9UI76KZL3ZopijwRO+JFe6X6F9iNmwBBf8J5TyL4OmIHR+a/4NlGbvZauS18HXzrrcV7NN1MpVWLLaHacM5DAboCDUFW2a+u4NaJOwC3yu/1lCaIeoAhBo9Tlde/xb8kiMHrmmGxAFUXiXOZ4tOeS6E1G9yWkqPlAbfzVyvCtnM2K3xVxBLudy3MvbCX4Fid12kTiAAOpjM/G4mQmY+99pf5Edv/f8iHhfNiQ6YZk5Wt265MNUUxi2G0PX3lNONO9YUbD0KKZAEmAaS4QVab2LpqBBcTw2axQ5CfYYgh1MobgU5Vij18EkXEMj6rQ3Xp/6c1B2kBTKG3oUqChaaX+caOg9bXKoSq3GTdiT/mY6t/KxkQF47no41V5YhgrC6LHVZ3f9wk/yjh0DorRy/kMyI5/E7Zwhv5h+6cA1xFsPIdIkQ6yV96+Voz2TFqOLs4kFmPVWNWN5ceTqgXPXBqv847aLOelLoWu0njHUUJLf0LjeGm4ptZbtnt6a60MCEM6mxqmx7Z6qizVofYOLwNP0k9iURkVKyHYqmJRCZFcm8FlfbMVXf4NQ1x5CMWXI4O8jhk1Lzwagg4tk3JjBweUTx0K61oufEZsADg==8OXh-----END PGP SIGNATURE-----
M
M
Mark H Weaver wrote on 28 Aug 2019 20:46
(name . Jakob L. Kreuze)(address . zerodaysfordays@sdf.lonestar.org)
875zmhm8jo.fsf@netris.org
Hi Jakob,
zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:
Toggle quote (5 lines)> Thanks for the input; I wasn't aware that the activation process was> taking so long for some people. One of Ludovic's suggestions was to> create a single derivation, rather than three, to speed up system> activation. I'll look into this further.
To be clear, I don't care how long it takes to build these derivations.However, I think they should all be built before starting to activatethe system. Does that make sense?
On a side note, what would happen if one of those builds failed? Wouldthe system activation be left half-done?
Thanks, Mark
J
J
Jakob L. Kreuze wrote on 29 Aug 2019 02:08
(name . Mark H Weaver)(address . mhw@netris.org)
87k1awomto.fsf@sdf.lonestar.org
Hi Mark,
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (13 lines)> Hi Jakob,>> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:>>> Thanks for the input; I wasn't aware that the activation process was>> taking so long for some people. One of Ludovic's suggestions was to>> create a single derivation, rather than three, to speed up system>> activation. I'll look into this further.>> To be clear, I don't care how long it takes to build these> derivations. However, I think they should all be built before starting> to activate the system. Does that make sense?
Yes, and I agree that it would be ideal to have the derivations builtprior to system activation -- that way, the activation scripts could beincluded in 'show-what-to-build*'.
Toggle quote (3 lines)> On a side note, what would happen if one of those builds failed? Would> the system activation be left half-done?
Yes. You raise another very good reason for why system activation shouldbe carried out by a single, atomic activation script :)
Regards,Jakob
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl1nF3MACgkQ9Qb9Fp2P2Voaew/9HFix6uBnigXRQc/XKlacYPkV/cPIYXvcTwSQvvq+bDYCGtCvRh5rO+3XaVF99yG3vy73lMY+f0ap6ZyGsdx2b4y6dp4MIrq7WdqKh2cV1tJwDKO+nisYKICuFTYv6bJs+68GGWLKd/qSGf+r7kvZwfWNu486NTqIJVtiwJls0z66WmdKtvKXvCl3Sd3wnfpj+QlfBu4iaVXqEeraQrQTw06XXIy8Du6U6jG8sbCTDxv57MPYGe69K9HuMBMG0gdAr3x7n6rCn1FJFhetns+ZLtLfPYc9/rbKEVYr7BD+xl44WRGr2/Yl3NzMuGFwK4vflQdhyTVi+c9JIGAke6RGEmKR0meI89YN4O7UHTnrqk8uvOJn0EyOt1X8jWYYJRbzXbBx/WGoZglksaN2ehdF9rJKx+OSchwlGi9jbaLcyeU8la5udbvyx2ukca4GucHhgVPaSBP2RNnMyZaMA3cFveLUssKugplGkD/eKvfLjHbtGwabFnTh0eIUY1y+Qh8wIqqWIdDAVkEXeHjZHkv5ueiPru1kW6LAldCkm4MMkL2oyPPVCXdNM7P5Wz4JjpEqgiDvetyhXYoXW8erPDNlqeQVG7D1vXLARJ8c/xLPJKTJoOizfNKyZuiRMDrPeqDGcAa+v38tsDiBgWEuj5zHmehquTi/KwBVjmYPTrA0ugw==TWMS-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 6 Nov 2019 18:46
control message for bug #36855
(address . control@debbugs.gnu.org)
87woccvqxx.fsf@gnu.org
merge 36855 37596quit
L
L
Ludovic Courtès wrote on 6 Nov 2019 18:46
(address . control@debbugs.gnu.org)
87v9rwvqxf.fsf@gnu.org
retitle 36855 'guix system switch-generation' does not reload Shepherd servicesquit
L
L
Ludovic Courtès wrote on 6 Nov 2019 18:46
(address . control@debbugs.gnu.org)
87tv7gvqxa.fsf@gnu.org
severity 36855 importantquit
B
B
Brice Waegeneire wrote on 9 Mar 08:01 +0100
Re: bug#37596: 'guix system switch-generation' does not reload Shepherd services
(name . Robert Vollmert)(address . rob@vllmrt.net)
877dmgzu7l.fsf@waegenei.re
Hello Guix,
To summarise the whole thread, in addition to the main issue explainedin the title “'guix system switch-generation' does not reload Shepherdservices“ there are 2 other issues talked about.
1. The activation script isn't executed by 'guix system switch-generation', which is fixed in df138dc20858725b90ed77be85f3318cbe1be73a and later.2. The activation process isn't exclusivly build during the system building process, whihc may the leave the system in half-hazard state if the building taking place during the activation fail.
The second side issue should proablby have it's own bug report sinceit's still present and we should keep that bug report only for the lackof reloading of shepherd service when using 'guix systemswitch-generation' (or 'roll-back').
Cheers,- Brice
?