'guix system reconfigure' must start/restart/stop services

Done

Details

4 participants

Carlo Zancanaro
Thompson, David
Efraim Flashner
Ludovic Courtès

Owner: Somebody

Submitted by: Ludovic Courtès

Severity: important

Ludovic Courtès wrote on 28 Nov 2015 17:35

Recipients:(address . bug-guix@gnu.org)

Message-ID:874mg6rsjl.fsf@gnu.org

Hello!

Currently ‘guix system reconfigure’ doesn’t try to dynamically update

the set of running services, which is a shame.

A simple strategy would be to have it:

1. Stop and unregister services currently known to dmd that are

missing in the new configuration.

2. Load and start (if they have ‘auto-start?’) services that are in

the new configuration and currently unknown to dmd.

3. The rest is the most difficult part: dealing with services that

already exist but that have changed (see below.)

One step towards this has been the fact that each service has its code

in a module of its own (commit fae685b), making it easy to have dmd load

it.

For #3, the difficulty is that we cannot do deco stop/load/start for

core services like udev or file-system-root because stopping these would

effectively halt the system.

However, we can safely restart services that are leaves of the dmd graph

(unless the user explicitly asks not to do it.) Here’s what it would

mean on my system, which uses ‘%desktop-services’ and a few more:

Toggle snippet (21 lines)scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> ,use(gnu)
scheme@(guile-user)> ,use(gnu services dmd)
scheme@(guile-user)> (define os (load "/home/ludo/src/configuration/pluto-configuration.scm"))
scheme@(guile-user)> ,use(gnu services)
scheme@(guile-user)> (define dmds (fold-services (operating-system-services os)
						 #:target-type dmd-root-service-type))
scheme@(guile-user)> ,use(gnu services)
scheme@(guile-user)> (length (service-parameters dmds))
$2 = 49
scheme@(guile-user)> (define back-edges (dmd-service-back-edges (service-parameters dmds)))
scheme@(guile-user)> ,use(srfi srfi-1)
scheme@(guile-user)> (map dmd-service-provision
			  (filter (lambda (s)
				    (null? (back-edges s)))
				(service-parameters dmds)))
$3 = ((swap-/dev/sda4) (nscd) (guix-daemon) (console-font-tty6) (console-font-tty5) (console-font-tty4) (console-font-tty3) (console-font-tty2) (console-font-tty1) (ntpd) (elogind) (upower-daemon) (avahi-daemon) (xorg-server) (tor) (ssh-daemon) (bitlbee))
scheme@(guile-user)> (length $3)
$4 = 17

17 out of 49 services could be restarted.

As a first step, we could ignore the other services.

As a second step, we could maybe have an ‘upgrade’ action that would

mutate their <service> instance in place, but without actually

restarting them, such that the changes would only take effect on the

next restart.

Roughly, we’d be doing, say:

deco upgrade udev /gnu/store/…-dmd-udev.scm

where …-dmd-udev.scm is the service file that contains:

(make <service> #:provides '(udev) …)

The ‘upgrade’ action would ‘set!’ all the fields of the old service

instance to those of the new instance, such that they are ‘equal?’ (but

not ‘eq?’.) The caveat is that this is not atomic.

Thoughts?

The prerequisite to all this work is to make the dmd RPCs

machine-processable, which is not too much work.

Thanks,

Ludo’.

Ludovic Courtès wrote on 8 Jan 2016 11:04

Recipients:(address . 22039@debbugs.gnu.org)

Message-ID:87d1tcmlpd.fsf@gnu.org

ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (3 lines)

> The prerequisite to all this work is to make the dmd RPCs

> machine-processable, which is not too much work.

Commit 841b009 in dmd does one step in that direction: it’s now possible

to get the status of services as an sexp.

Ludo’.

Ludovic Courtès wrote on 3 Feb 2016 22:32

Recipients:(address . 22039@debbugs.gnu.org)

Message-ID:87h9hp7a5h.fsf@gnu.org

ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (14 lines)> Currently ‘guix system reconfigure’ doesn’t try to dynamically update
> the set of running services, which is a shame.
>
> A simple strategy would be to have it:
>
>   1. Stop and unregister services currently known to dmd that are
>      missing in the new configuration.
>
>   2. Load and start (if they have ‘auto-start?’) services that are in
>      the new configuration and currently unknown to dmd.
>
>   3. The rest is the most difficult part: dealing with services that
>      already exist but that have changed (see below.)

Commit 240b57f implements #1 and #2.

Ludo’.

Thompson, David wrote on 3 Feb 2016 22:34

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:CAJ=Rwfb=dw9QudA-yWnYTj4NVUH=qO7UXTzW6BXEtza5mTM66g@mail.gmail.com

On Wed, Feb 3, 2016 at 4:32 PM, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (18 lines)> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> Currently ‘guix system reconfigure’ doesn’t try to dynamically update
>> the set of running services, which is a shame.
>>
>> A simple strategy would be to have it:
>>
>>   1. Stop and unregister services currently known to dmd that are
>>      missing in the new configuration.
>>
>>   2. Load and start (if they have ‘auto-start?’) services that are in
>>      the new configuration and currently unknown to dmd.
>>
>>   3. The rest is the most difficult part: dealing with services that
>>      already exist but that have changed (see below.)
>
> Commit 240b57f implements #1 and #2.

Awesome! This is very good progress.

- Dave

Ludovic Courtès wrote on 18 Apr 2016 16:52

control message for bug #22039

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87oa973r6j.fsf@gnu.org

owner 22039 !

Ludovic Courtès wrote on 16 Jan 2018 12:16

Recipients:(address . control@debbugs.gnu.org)

Message-ID:871siq835n.fsf@gnu.org

severity 22039 important

Ludovic Courtès wrote on 16 Jan 2018 12:17

‘guix system reconfigure’ does not always load new services

Recipients:(address . 22039@debbugs.gnu.org)

Message-ID:87wp0i6ojv.fsf@gnu.org

Forwarded from

https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00187.html.

Attachment: file

Carlo Zancanaro wrote on 26 Aug 2018 14:15

[PATCH] 'guix system reconfigure' must start/restart/stop services

Recipients:(address . 22039@debbugs.gnu.org)

Message-ID:87tvnhxr20.fsf@zancanaro.id.au

When the next release of the Shepherd is made (including commit 
9ec5c0000e9a45441417a6ee4138cdcbf1b1f2b2) we should have the 
capability to resolve this ticket.

Attached is my proposed patch from the Guix side. I have tested it 
on my machine by grafting the Shepherd with the appropriate patch 
and it seems to work as expected.

I tested it by changing the substitute-urls in my guix-daemon 
configuration. The output of `ps aux | grep guix-daemon` after 
`guix system reconfigure` showed the substitute-urls were 
unchanged. After `herd restart guix-daemon` the updated 
substitute-urls appeared in `ps aux | grep guix-daemon`. I did not 
need to reboot my system.

One possible improvement would be to print out the services that 
need to be restarted to be upgraded.

From 162bd298563201ebf6eda87d46ae1b64671397da Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro <carlo@zancanaro.id.au>
Date: Sun, 26 Aug 2018 21:54:14 +1000
Subject: [PATCH] gnu: services: Load all services on reconfigure, not just
 stopped ones

* gnu/services/shepherd.scm (shepherd-service-upgrade): Remove checks for
running services.
---
 gnu/services/shepherd.scm | 25 +++++--------------------
 1 file changed, 5 insertions(+), 20 deletions(-)

Toggle diff (54 lines)diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index 4cd224984..efeb82c86 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015, 2016, 2018 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2017 Clément Lassieur <clement@lassieur.org>
+;;; Copyright © 2018 Carlo Zancanaro <carlo@zancanaro.id.au>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -338,20 +339,6 @@ needs to be loaded."
     (shepherd-service-lookup-procedure target
                                        shepherd-service-provision))
 
-  (define lookup-live
-    (shepherd-service-lookup-procedure live
-                                       live-service-provision))
-
-  (define (running? service)
-    (and=> (lookup-live (shepherd-service-canonical-name service))
-           live-service-running))
-
-  (define (stopped service)
-    (match (lookup-live (shepherd-service-canonical-name service))
-      (#f #f)
-      (service (and (not (live-service-running service))
-                    service))))
-
   (define live-service-dependents
     (shepherd-service-back-edges live
                                  #:provision live-service-provision
@@ -363,14 +350,12 @@ needs to be loaded."
       (_  #f)))
 
   (define to-load
-    ;; Only load services that are either new or currently stopped.
-    (remove running? target))
+    ;; Load all of the new services.
+    target)
 
   (define to-unload
-    ;; Unload services that are (1) no longer required, or (2) are in TO-LOAD.
-    (remove essential?
-            (append (filter obsolete? live)
-                    (filter-map stopped to-load))))
+    ;; Unload services that are no longer required.
+    (remove essential? (filter obsolete? live)))
 
   (values to-unload to-load))
 
-- 
2.18.0

Ludovic Courtès wrote on 1 Sep 2018 12:49

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039@debbugs.gnu.org)

Message-ID:87sh2tijb2.fsf@gnu.org

Hi Carlo,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

Toggle quote (4 lines)

> When the next release of the Shepherd is made (including commit

> 9ec5c0000e9a45441417a6ee4138cdcbf1b1f2b2) we should have the

> capability to resolve this ticket.

Woohoo!

I’d like to make sure we understand the story with ‘EINTR-safe’, but

after that I’m happy to push a release.

Toggle quote (10 lines)> Attached is my proposed patch from the Guix side. I have tested it on
> my machine by grafting the Shepherd with the appropriate patch and it
> seems to work as expected.
>
> I tested it by changing the substitute-urls in my guix-daemon
> configuration. The output of `ps aux | grep guix-daemon` after `guix
> system reconfigure` showed the substitute-urls were unchanged. After
> `herd restart guix-daemon` the updated substitute-urls appeared in `ps
> aux | grep guix-daemon`. I did not need to reboot my system.

Perfect.

Toggle quote (3 lines)

> One possible improvement would be to print out the services that need

> to be restarted to be upgraded.

Yes, that’d be nice.

Toggle quote (9 lines)

> From 162bd298563201ebf6eda87d46ae1b64671397da Mon Sep 17 00:00:00 2001

> From: Carlo Zancanaro <carlo@zancanaro.id.au>

> Date: Sun, 26 Aug 2018 21:54:14 +1000

> Subject: [PATCH] gnu: services: Load all services on reconfigure, not just

> stopped ones

> * gnu/services/shepherd.scm (shepherd-service-upgrade): Remove checks for

> running services.

Could you adjust the manual, where it currently says “if a service is

currently running, it does not attempt to upgrade it”?

Other than that LGTM!

Ludo’.

Carlo Zancanaro wrote on 1 Sep 2018 14:15

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:87va7pza4p.fsf@zancanaro.id.au

Hey Ludo’,

On Sat, Sep 01 2018, Ludovic Courtès wrote:

Toggle quote (3 lines)

> I’d like to make sure we understand the story with ‘EINTR-safe’,

> but after that I’m happy to push a release.

Do you have any thoughts about why it could be failing, or things

I could investigate? I don't know where to start.

Toggle quote (5 lines)

>> One possible improvement would be to print out the services

>> that need to be restarted to be upgraded.

> Yes, that’d be nice.

I have done this, but now it seems a bit overwhelming how many 
services would need to be manually restarted. My modified code 
writes a message like this:

To complete the upgrade, restart the following services:
    file-systems
    user-file-systems
    file-system-/boot/efi
    file-system-/dev/pts
    file-system-/dev/shm
    file-system-/gnu/store
    file-system-/run/systemd
    file-system-/run/user
    file-system-/sys/fs/cgroup/elogind
    file-system-/sys/fs/cgroup
    file-system-/sys/fs/cgroup/cpuset
    file-system-/sys/fs/cgroup/cpu
    file-system-/sys/fs/cgroup/cpuacct
    file-system-/sys/fs/cgroup/memory
    file-system-/sys/fs/cgroup/devices
    file-system-/sys/fs/cgroup/freezer
    file-system-/sys/fs/cgroup/blkio
    file-system-/sys/fs/cgroup/perf_event
    root-file-system
    user-processes
    host-name
    udev
    nscd
    guix-daemon
    urandom-seed
    syslogd
    loopback
    term-tty6
    term-tty5
    term-tty4
    term-tty3
    term-tty2
    term-tty1
    console-font-tty1
    console-font-tty2
    console-font-tty3
    console-font-tty4
    console-font-tty5
    console-font-tty6
    virtual-terminal
    ntpd
    dbus-system
    elogind
    upower-daemon
    avahi-daemon
    wpa-supplicant
    networking
    xorg-server
    cups

The same list is printed every time on my system, because the 
diffing is only on the level of the canonical-name. Most of these 
services are being "replaced" by services that are exactly the 
same, so they don't really need to be restarted. I don't really 
know what to do about this, Even if it were fixed, on an actual 
upgrade I assume many of these services would be different, and 
thus would be printed legitimately.

I'm also confused why some of these things are services (like 
host-name).

I'll send through an updated patch once I've cleaned it up a bit, 
but I'm not as positive about it as I was initially.

Carlo

Carlo Zancanaro wrote on 1 Sep 2018 14:33

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:87tvn9z9bp.fsf@zancanaro.id.au

On Sat, Sep 01 2018, Carlo Zancanaro wrote:

Toggle quote (3 lines)

> I'll send through an updated patch once I've cleaned it up a

> bit, [ ... ]

Updated patch attached.

Attachment: 0001-gnu-services-Load-all-services-on-reconfigure-not-ju.patch

Ludovic Courtès wrote on 1 Sep 2018 19:12

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039@debbugs.gnu.org)

Message-ID:87tvn9b0qh.fsf@gnu.org

Heya,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

Toggle quote (7 lines)

> On Sat, Sep 01 2018, Ludovic Courtès wrote:

>> I’d like to make sure we understand the story with ‘EINTR-safe’, but

>> after that I’m happy to push a release.

> Do you have any thoughts about why it could be failing, or things I

> could investigate? I don't know where to start.

First, could you check (in a VM) whether the boot failure is

reproducible when that patch that removes ‘EINTR-safe’ is applied?

If it’s 100% reproducible, could you share the VM’s output?

I don’t know what the problem might be but hopefully that’ll give us a

starting point.

Toggle quote (4 lines)

> I have done this, but now it seems a bit overwhelming how many

> services would need to be manually restarted. My modified code writes

> a message like this:

[...]

Toggle quote (8 lines)

> The same list is printed every time on my system, because the diffing

> is only on the level of the canonical-name. Most of these services are

> being "replaced" by services that are exactly the same, so they don't

> really need to be restarted. I don't really know what to do about

> this, Even if it were fixed, on an actual upgrade I assume many of

> these services would be different, and thus would be printed

> legitimately.

Indeed. In addition, some low-level services such as file system mounts

cannot be restarted without rebooting, so it’s not useful to mention

them. Perhaps we should simply print (1) the list of services that were

restarted, and (2) a message saying that users should explicitly run

“herd restart SERVICE” to upgrade other services.

WDYT?

Toggle quote (3 lines)

> I'm also confused why some of these things are services (like

> host-name).

‘host-name’ could (should?) be an activation snippet.

Thank you!

Ludo’.

Carlo Zancanaro wrote on 2 Sep 2018 05:43

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:87tvn8d0n7.fsf@zancanaro.id.au

On Sun, Sep 02 2018, Ludovic Courtès wrote:

Toggle quote (4 lines)

> First, could you check (in a VM) whether the boot failure is

> reproducible when that patch that removes ‘EINTR-safe’ is

> applied?

As far as I can tell it's completely reproducible.

Toggle quote (2 lines)

> If it’s 100% reproducible, could you share the VM’s output?

Sure. It's attached.

Attachment: vm-output

Toggle quote (9 lines)

> Indeed. In addition, some low-level services such as file

> system mounts cannot be restarted without rebooting, so it’s not

> useful to mention them. Perhaps we should simply print (1) the

> list of services that were restarted, and (2) a message saying

> that users should explicitly run “herd restart SERVICE” to

> upgrade other services.

> WDYT?

If there are services that must never be restarted, then maybe we 
don't want to indiscriminately print out a message to restart 
everything. We need some way to mark services that must not be 
restarted. If that's the case, then we might as well just 
automatically restart the services that we can rather than 
printing a message saying to do so. What do we gain by adding an 
extra step to that process?

Carlo

Ludovic Courtès wrote on 2 Sep 2018 22:39

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039@debbugs.gnu.org)

Message-ID:87y3cj4orq.fsf@gnu.org

Hi Carlo,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

Toggle quote (13 lines)> [   18.924085] shepherd[1]: Service root-file-system has been started.
> [   18.932361] shepherd[1]: 
> [   18.939972] shepherd[1]: Service user-file-systems has been started.
> [   18.947889] shepherd[1]: 
> [   18.989611] shepherd[1]: waiting for udevd...
> [   19.001396] shepherd[1]: 
> [   19.229174] udevd[267]: starting version 3.2.5
> failed to start service 'file-systems'
> could not create '/dev/autofs': File exists
> could not create '/dev/fuse': File exists
> could not create '/dev/cuse': File exists
> [   19.525763] udevd[267]: starting eudev-3.2.5

[...]

Toggle quote (3 lines)

> [ 19.553794] udevd[267]: no sender credentials received, message ignored

> failed to start service 'file-system-/dev/pts'

[...]

Toggle quote (3 lines)

> [ 19.633995] udevd[267]: no sender credentials received, message ignored

> failed to start service 'file-system-/dev/shm'

[...]

Toggle quote (9 lines)

> [ 19.741025] udevd[267]: no sender credentials received, message ignored

> failed to start service 'user-processes'

> [ 19.773968] shepherd[1]: Service host-name has been started.

> [ 19.784495] udevd[268]: starting version 3.2.5

> [ 19.797674] shepherd[1]:

> could not create '/dev/autofs': File exists

> could not create '/dev/fuse': File exists

> [ 19.846310] udevd[269]: starting version 3.2.5

It looks as if udev failed to start initially, hence the subsequent
“failed to start 'file-system-*'” messages, but then we appear to have
several competing udevd processes, as if (exec-command (list udevd)) had
been executed multiple times.  Hmm not sure what’s going on…

Ludo’.

Ludovic Courtès wrote on 19 Sep 2018 17:47

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039@debbugs.gnu.org)

Message-ID:87lg7xh4l0.fsf@gnu.org

Hi Carlo,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

Toggle quote (6 lines)

> On Sun, Sep 02 2018, Ludovic Courtès wrote:

>> First, could you check (in a VM) whether the boot failure is

>> reproducible when that patch that removes ‘EINTR-safe’ is applied?

> As far as I can tell it's completely reproducible.

Commit c4ba8c79db0aa4ba3517acc82ebafe16105fbb97 reinstates the commit

and removes the leftover #:replace, which was responsible for the

problem: in the context of the ‘start’ method of udev, ‘system*’ was

unbound, to ‘start’ would throw an exception and shepherd would call it

again (thinking udev had failed to start), indefinitely.

If there’s nothing left to add to Shepherd, we can release 0.5.0 within

a few days and then commit the Guix side of this change.

WDYT?

Thanks,

Ludo’.

Carlo Zancanaro wrote on 19 Sep 2018 22:56

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:871s9pfbpg.fsf@zancanaro.id.au

Hey Ludo’,

On Thu, Sep 20 2018, Ludovic Courtès wrote:

Toggle quote (4 lines)

> Commit c4ba8c79db0aa4ba3517acc82ebafe16105fbb97 reinstates the

> commit and removes the leftover #:replace, which was responsible

> for the problem: ...

That's great! I didn't even know about the #:replace option, so

I'm glad you were able to find it.

Toggle quote (3 lines)

> If there’s nothing left to add to Shepherd, we can release 0.5.0

> within a few days and then commit the Guix side of this change.

This seems like the sort of thing that shouldn't have been this 
tricky. Is the exception printed somewhere? If not, then I think 
we should print the exception, or at least some information, when 
a service fails to load.

Carlo

Ludovic Courtès wrote on 20 Sep 2018 11:47

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039@debbugs.gnu.org)

Message-ID:87efdowleu.fsf@gnu.org

Hi,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

Toggle quote (16 lines)> On Thu, Sep 20 2018, Ludovic Courtès wrote:
>> Commit c4ba8c79db0aa4ba3517acc82ebafe16105fbb97 reinstates the
>> commit and removes the leftover #:replace, which was responsible for
>> the problem: ...
>
> That's great! I didn't even know about the #:replace option, so I'm
> glad you were able to find it.
>
>> If there’s nothing left to add to Shepherd, we can release 0.5.0
>> within a few days and then commit the Guix side of this change.
>
> This seems like the sort of thing that shouldn't have been this
> tricky. Is the exception printed somewhere? If not, then I think we
> should print the exception, or at least some information, when a
> service fails to load.

I agree. Note that ‘herd start foo’ prints at least a one-line message

showing the exception when that happens. The problem here is that

failure happens when ‘start’ is called from the shepherd config file.

At that point there’s no client connected and syslogd either around

either, so presumably messages go to /dev/kmsg and/or the console.

I wouldn’t consider it a blocker for 0.5.0 though. WDYT?

Thanks,

Ludo’.

Carlo Zancanaro wrote on 20 Sep 2018 12:24

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:87tvmkqxe7.fsf@zancanaro.id.au

Toggle quote (2 lines)

> [...] so presumably messages go to /dev/kmsg and/or the console.

I don't remember seeing anything about the exception in any of the

output that I looked at. I'm a bit confused about where different

bits of output go, so I'll take a look at how output is handled in

a few weeks, when the rest of life settles down a bit.

Toggle quote (2 lines)

> I wouldn’t consider it a blocker for 0.5.0 though. WDYT?

Yeah, I agree. We should try to improve it, but as long as we

haven't made things worse (which we haven't) then it shouldn't

block a release.

We still need to work out what we want to do on the Guix side once

the Shepherd is released. Do we want to restart services that we

can, or print a message telling users how to do so? Maybe

individual services should be able to specify their preference?

Carlo

Ludovic Courtès wrote on 20 Sep 2018 13:08

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039@debbugs.gnu.org)

Message-ID:87efdov32l.fsf@gnu.org

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

Toggle quote (5 lines)

> We still need to work out what we want to do on the Guix side once the

> Shepherd is released. Do we want to restart services that we can, or

> print a message telling users how to do so? Maybe individual services

> should be able to specify their preference?

I would reload and restart services currently stopped (what ‘guix system

reconfigure’ currently does), and replace all the other services. This

is what the patch you sent at https://issues.guix.info/issue/22039#24

does.

AIUI the only remaining issue is whether/how to print hints about

services that need to be manually restarted. In

https://issues.guix.info/issue/22039#36 I wrote:

Toggle quote (4 lines)

> Perhaps we should simply print (1) the list of services that were

> restarted, and (2) a message saying that users should explicitly run

> “herd restart SERVICE” to upgrade other services.

To which you replied:

Toggle quote (8 lines)

> If there are services that must never be restarted, then maybe we

> don't want to indiscriminately print out a message to restart

> everything. We need some way to mark services that must not be

> restarted. If that's the case, then we might as well just

> automatically restart the services that we can rather than

> printing a message saying to do so. What do we gain by adding an

> extra step to that process?

From the POV of the Shepherd, services carry no semantics. The Shepherd

cannot guess that restarting ‘udev’ or ‘file-system-xyz’ is impractical

(try it :-)). Leaf services like ‘ssh-daemon’ can generally be

restarted, but whether or not now is a good time to do it is something

only the user can decide. That’s why the only services which are safe

to restart right away are those currently stopped (and those that can be

hot-swapped like nginx.)

Thus I think it’s reasonable to print a message along the lines of:

The following services were upgraded: …

Please run “herd restart SERVICE” to stop, upgrade, and restart

services that were not automatically upgraded.

WDYT?

Thanks,

Ludo’.

Carlo Zancanaro wrote on 20 Sep 2018 13:50

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:87sh24qtes.fsf@zancanaro.id.au

Hey Ludo’,

Toggle quote (2 lines)

> From the POV of the Shepherd, services carry no semantics.

In Guix we have as much information as possible about the 
services. We should be know which services should be upgraded 
automatically, which ones we should prompt the user to upgrade, 
and which ones are never safe to upgrade. Maybe we could add a 
"restart-strategy" to the shepherd-service object?

Toggle quote (9 lines)

> Thus I think it’s reasonable to print a message along the lines

> of:

> The following services were upgraded: …

> Please run “herd restart SERVICE” to stop, upgrade, and

> restart services that were not automatically upgraded.

> WDYT?

The main reasons I'm not super happy with this are that it's not 
discoverable (which is bad for new users), and it requires 
interaction (so cannot be an unattended upgrade). In particular 
for discoverability, some of our services don't take advantage of 
the Shepherd's ability to have multiple "provision" values. For 
instance, I just have to know that to restart wicd I have to run 
"herd restart networking".

Maybe this should be a separate ticket. Replacing the services and 
printing a generic message will still be an improvement on what 
Guix currently does, and I don't want to hold that up just because 
I think we can do better.

Carlo

Ludovic Courtès wrote on 21 Sep 2018 13:58

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039@debbugs.gnu.org)

Message-ID:87r2hn2hbo.fsf@gnu.org

Hello,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

Toggle quote (8 lines)

>> From the POV of the Shepherd, services carry no semantics.

> In Guix we have as much information as possible about the services. We

> should be know which services should be upgraded automatically, which

> ones we should prompt the user to upgrade, and which ones are never

> safe to upgrade. Maybe we could add a "restart-strategy" to the

> shepherd-service object?

What would you put there? Do you have concrete examples?

Note that FHS distros don’t do better: either the service is

hot-replaceable (nginx; I don’t know of any other) or can at least

reload its config (sshd, etc.), and then it’s dynamically upgraded, or

it’ll be upgraded next time you restart it.

That’s because fundamentally only the user can tell whether now is a

good time to restart, say, sshd.

In Debian, “apt-get dist-upgrade” opens a dialog box asking the user

whether services can be restarted right away, IIRC.

Toggle quote (12 lines)>> Thus I think it’s reasonable to print a message along the lines of:
>>
>>   The following services were upgraded: …
>>   Please run “herd restart SERVICE” to stop, upgrade, and   restart
>> services that were not automatically upgraded.
>>
>> WDYT?
>
> The main reasons I'm not super happy with this are that it's not
> discoverable (which is bad for new users), and it requires interaction
> (so cannot be an unattended upgrade).

I agree, but I don’t think full unattended upgrades exist out there.

I’m not saying this is good, but rather that this is hard and beyond

the scope of this patch.

Toggle quote (5 lines)

> In particular for discoverability, some of our services don't take

> advantage of the Shepherd's ability to have multiple "provision"

> values. For instance, I just have to know that to restart wicd I have

> to run "herd restart networking".

There’s ‘guix system search’ that provides this kind of info (see

https://issues.guix.info/issue/29707), but I agree we could do better.

Toggle quote (5 lines)

> Maybe this should be a separate ticket. Replacing the services and

> printing a generic message will still be an improvement on what Guix

> currently does, and I don't want to hold that up just because I think

> we can do better.

Yes, I think this should be a separate ticket. We can go with your

patch and a message along the lines of what we discussed above, and then

work on the improvements you mentioned, one at a time. That way we’ll

have the warm feeling of having achieved something, even if there’s more

to come. :-)

Thank you!

Ludo’.

Efraim Flashner wrote on 23 Sep 2018 10:26

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:20180923082613.GA1226@macbook41

On Fri, Sep 21, 2018 at 01:58:03PM +0200, Ludovic Courtès wrote:

Toggle quote (14 lines)> Hello,
> 
> Carlo Zancanaro <carlo@zancanaro.id.au> skribis:
> 
> >> From the POV of the Shepherd, services carry no semantics.
> >
> > In Guix we have as much information as possible about the services. We
> > should be know which services should be upgraded automatically, which
> > ones we should prompt the user to upgrade, and which ones are never
> > safe to upgrade. Maybe we could add a "restart-strategy" to the
> > shepherd-service object?
> 
> What would you put there?  Do you have concrete examples?

Restart/reload/whatever unless explicitly disabled?

Toggle quote (9 lines)

> Note that FHS distros don’t do better: either the service is

> hot-replaceable (nginx; I don’t know of any other) or can at least

> reload its config (sshd, etc.), and then it’s dynamically upgraded, or

> it’ll be upgraded next time you restart it.

> That’s because fundamentally only the user can tell whether now is a

> good time to restart, say, sshd.

Not exactly the point, but Debian regularly restarts sshd for me on a

remote box (somehow) without me losing the connection.

Toggle quote (13 lines)> 
> In Debian, “apt-get dist-upgrade” opens a dialog box asking the user
> whether services can be restarted right away, IIRC.
> 
> >> Thus I think it’s reasonable to print a message along the lines of:
> >>
> >>   The following services were upgraded: …
> >>   Please run “herd restart SERVICE” to stop, upgrade, and   restart
> >> services that were not automatically upgraded.
> >>
> >> WDYT?
> 

This sounds like a really good idea, especially if we limit to ones that

are less likely to cause problems if restarted (like filesystems). We

still have to figure out something for databases and upgrading them from

one version to another.

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

Ludovic Courtès wrote on 23 Sep 2018 21:53

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)

Message-ID:87lg7srnw0.fsf@gnu.org

Hi,

Efraim Flashner <efraim@flashner.co.il> skribis:

Toggle quote (2 lines)

> On Fri, Sep 21, 2018 at 01:58:03PM +0200, Ludovic Courtès wrote:

[...]

Toggle quote (11 lines)>> Note that FHS distros don’t do better: either the service is
>> hot-replaceable (nginx; I don’t know of any other) or can at least
>> reload its config (sshd, etc.), and then it’s dynamically upgraded, or
>> it’ll be upgraded next time you restart it.
>> 
>> That’s because fundamentally only the user can tell whether now is a
>> good time to restart, say, sshd.
>
> Not exactly the point, but Debian regularly restarts sshd for me on a
> remote box (somehow) without me losing the connection.

Good point!  I think sshd opens child processes for new sessions, and
thanks to that it falls into the category of service that can be
hot-replaced.

For hot-swappable daemons, I think we should provide a specific ‘reload’
or ‘upgrade’ action as was discussed at
https://issues.guix.info/issue/26830.  That way, to figure out the
right strategy, we would just check whether the service supports that
action.

Thanks,
Ludo’.

Carlo Zancanaro wrote on 24 Sep 2018 01:06

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:87lg7ru83l.fsf@zancanaro.id.au

Hey Ludo’,

On Fri, Sep 21 2018, Ludovic Courtès wrote:

Toggle quote (2 lines)

> What would you put there? Do you have concrete examples?

I would have three possible values: 'never, 'always, 'manual.

'never would mean that the service should never be restarted. This 
is for things like udev, or the filesystems, which should never be 
restarted on a running system.

'always would mean that the service is always safe to restart. I 
don't immediately know what services would fit in this category 
(maybe sshd, given Efraim's comment; maybe ntpd? I'm sure there 
are others). Things like nginx will probably not fall into this 
category, because they involve some downtime when restarting. 
Reloading their configuration (via a "reload" action, or similar) 
is not enough because the binary and/or libraries might have 
changed (and, in the worst case, might have an incompatible 
configuration format, although I would expect that to be 
exceedingly rare).

'manual would mean that the service should be restarted, but it 
need to be done at an appropriate time. This should prompt the 
user with the names of the services, and we should provide an 
option to guix system reconfigure to restart these services as 
part of the reconfigure. We could call the option 
"--restart-services".

Toggle quote (7 lines)

>> [ ... ] I just have to know that to restart wicd I have to run

>> "herd restart networking".

> There’s ‘guix system search’ that provides this kind of info

> (see <https://issues.guix.info/issue/29707>), but I agree we

> could do better.

I actually checked this before sending my previous message, but I 
didn't see that it includes "shepherdnames". I tested with "guix 
system search wicd" which didn't show any, but I see now that 
searching "guix system search xmpp" does helpfully show how to 
restart the service.

Toggle quote (5 lines)

> We can go with your patch and a message along the lines of what

> we discussed above, and then work on the improvements you

> mentioned, one at a time. That way we’ll have the warm feeling

> of having achieved something, even if there’s more to come. :-)

I won't be able to look at writing the code for this for a few

weeks, but hopefully I'll get to it around mid- to late-October.

Carlo

Ludovic Courtès wrote on 24 Sep 2018 10:58

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039@debbugs.gnu.org)

Message-ID:877ejbxodp.fsf@gnu.org

Hi Carlo,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

Toggle quote (25 lines)> On Fri, Sep 21 2018, Ludovic Courtès wrote:
>> What would you put there?  Do you have concrete examples?
>
> I would have three possible values: 'never, 'always, 'manual.
>
> 'never would mean that the service should never be restarted. This is
> for things like udev, or the filesystems, which should never be
> restarted on a running system.
>
> 'always would mean that the service is always safe to restart. I don't
> immediately know what services would fit in this category (maybe sshd,
> given Efraim's comment; maybe ntpd? I'm sure there are others). Things
> like nginx will probably not fall into this category, because they
> involve some downtime when restarting. Reloading their configuration
> (via a "reload" action, or similar) is not enough because the binary
> and/or libraries might have changed (and, in the worst case, might
> have an incompatible configuration format, although I would expect
> that to be exceedingly rare).
>
> 'manual would mean that the service should be restarted, but it need
> to be done at an appropriate time. This should prompt the user with
> the names of the services, and we should provide an option to guix
> system reconfigure to restart these services as part of the
> reconfigure. We could call the option "--restart-services".

OK, I see.

Toggle quote (8 lines)

>> We can go with your patch and a message along the lines of what we

>> discussed above, and then work on the improvements you mentioned,

>> one at a time. That way we’ll have the warm feeling of having

>> achieved something, even if there’s more to come. :-)

> I won't be able to look at writing the code for this for a few weeks,

> but hopefully I'll get to it around mid- to late-October.

If that’s fine with you, I can apply the patch you initially posted so

we can start taking advantage of it (I’d like to push a Guix release by

the end of October.) WDYT?

Thanks!

Ludo’.

Carlo Zancanaro wrote on 24 Sep 2018 12:18

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22039@debbugs.gnu.org)

Message-ID:87k1nb5hbl.fsf@zancanaro.id.au

Hey Ludo’,

On Mon, Sep 24 2018, Ludovic Courtès wrote:

Toggle quote (4 lines)

> If that’s fine with you, I can apply the patch you initially

> posted so we can start taking advantage of it (I’d like to push

> a Guix release by the end of October.) WDYT?

That sounds good to me!

Thanks for your patience through this. It's taken a bit of time

for my ideas to fully form, but I think it's coming together.

Carlo

Ludovic Courtès wrote on 26 Sep 2018 23:46

Recipients:(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 22039-done@debbugs.gnu.org)

Message-ID:87y3boylsv.fsf@gnu.org

Hello!

I went ahead and pushed the patch as

4245ddcbc9f935804c17c97872b90ec1050c2d75.

One modification I had to make and which I hadn’t though of before is

the new ‘load-services/safe’ procedure I added: it makes sure it DTRT

when talking to shepherd < 0.15.0.

I’ve reconfigured from master, and so far so good! :-)

I’m closing this issue. I suggest opening new ones for specific

improvements we discussed.

Thank you!

Ludo’.

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 22039@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date