bug#22753: Shepherd: Problem reconfiguring from bare-bones to desktop

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> When I later build a full desktop system and reconfigured, several
> errors were reported by shepherd while attempting to update the running
> services, and some messages were missing trailing newlines.  Here's the
> tail of the console output:
>
> making '/gnu/store/q9k5c12m65l19jcpx8fm213jk542pi9m-system' the current 
> system...
> guix system: loading new services: ntpd elogind upower-daemon networking 
> avahi-daemon xorg-server bitlbee tor...
> guix system: shepherd: Evaluating user expression (register-services 
> (primitive-load "/gn...") ...).
> guix system: error: exception caught while executing 'eval' on service 
> 'root':ERROR: In procedure open-file: No such file or directory: 
> "/gnu/store/w5p4sxbwsmj1q9g95j4q909g6hwiksql-shepherd-tor.scm"
> Installation finished. No Error reported.
> guix system: error: service 'ntpd' could not be foundguix system: error: 
> service 'elogind' could not be foundguix system: error: service 
> 'upower-daemon' could not be foundguix system: error: service 'networking' 
> could not be foundguix system: error: service 'avahi-daemon' could not be 
> foundguix system: error: service 'xorg-server' could not be foundguix system: 
> error: service 'bitlbee' could not be foundguix system: error: service 'tor' 
> could not be foundroot:~#

The missing newlines were added in f2d8faf.

What’s happening here is that ‘guix system’ passes shepherd a list of
files to load (one file per service), but some of these files happen to
be nonexistent (notably shepherd-tor.scm.)  Because of that, it does not
even load subsequent service files.

Nevertheless, it happily tries to start all these services that failed
to be loaded, which results in this series of “could not be found”
messages.

(We should probably load services one at a time and keep track of which
one failed exactly.)

The service file names are computed in ‘upgrade-shepherd-services’:

--8<---------------cut here---------------start------------->8---
     (let ((to-load-names  (map shepherd-service-canonical-name to-load))
           (to-start       (filter shepherd-service-auto-start? to-load)))
       (info (_ "loading new services:~{ ~a~}...~%") to-load-names)
       (mlet %store-monad ((files (mapm %store-monad shepherd-service-file
                                        to-load)))
         ;; Here we assume that FILES are exactly those that were computed
         ;; as part of the derivation that built OS, which is normally the
         ;; case.
         (load-services (map derivation->output-path files))
--8<---------------cut here---------------end--------------->8---

The comment wasn’t there before but it explains the story: we call
‘shepherd-service-file’ here and normally, that gives us the same result
as what was already computed when building OS.

However, that assumption turned out to be wrong in some cases, hence the
error you got (the shepherd-tor.scm file we’re trying to load is
missing.)

It turns out that ‘shepherd-service-file’ was computing a slightly
different derivation for torrc and all these files.  The difference was
that it was using a different utils.scm file (for instance) in its
‘module-import’ and ‘module-import-compiled’ derivations induced by
‘gexp->derivation’.

The reason it was using a different utils.scm (namely
/gnu/store/…-utils.scm instead of /home/ludo/…/utils.scm) is that
the activation script, which is run just before
‘upgrade-shepherd-services’ is called, modified ‘%load-path’.

I’m not sure the above explanation is crystal clear, but suffice to say
that this is fixed in cfd5032.  :-)

Anyway, this was a good stress test.

Thanks,
Ludo’.