'guix system reconfigure' does not reload Shepherd services

> Hi,

>

> it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012

>

> guix system: Reimplement 'reconfigure’.

>

> breaks guix system reconfigure. In particular, after reconfiguring,

> shepherd doesn’t know about the updated versions of services.

>

> The usual output below is missing; after reverting the commit it’s

> fine again.

> I see that some system tests for “guix system reconfigure” were added

> after this change. Might I suggest adding them before the change next

> time around, and making sure they pass both before and after?

> On 31. Jul 2019, at 18:45, Jakob L. Kreuze <zerodaysfordays@sdf.lonestar.org> wrote:

> Robert Vollmert <rob@vllmrt.net> writes:

>

>> Hi,

>>

>> it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012

>>

>> guix system: Reimplement 'reconfigure’.

>>

>> breaks guix system reconfigure. In particular, after reconfiguring,

>> shepherd doesn’t know about the updated versions of services.

>>

>> The usual output below is missing; after reverting the commit it’s

>> fine again.

>

> Could you please elaborate on what you mean by this? I can see that the

> ouput has changed, but is Shepherd doing something that indicates that

> it doesn't know about the new services?

> And is the line regarding

> bootloader installation also missing from 'guix system reconfigure'

> post-5c8c8c455?

> The concrete problem is this:

>

> 1. nginx is running with config file A

> 2. make some change to nginx config

> 3. run guix system reconfigure (which builds a new nginx config file B)

> 4. run herd restart nginx

> 5. nginx is still running with config file A

>

> After reverting this commit, if I perform these steps, I end up with

> nginx running with config file B in 5.

> I still get a bootloader line.

> On 31. Jul 2019, at 20:16, Jakob L. Kreuze <zerodaysfordays@sdf.lonestar.org> wrote:

>

> Hi Robert,

>

> Robert Vollmert <rob@vllmrt.net> writes:

>

>> The concrete problem is this:

>>

>> 1. nginx is running with config file A

>> 2. make some change to nginx config

>> 3. run guix system reconfigure (which builds a new nginx config file B)

>> 4. run herd restart nginx

>> 5. nginx is still running with config file A

>>

>> After reverting this commit, if I perform these steps, I end up with

>> nginx running with config file B in 5.

>

> Okay, I see now. Thank you clarifying. Would you be willing to see if

> the patch provided by #36880 fixes this issue?

> Hi,

>

> it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012

>

> guix system: Reimplement 'reconfigure’.

>

> breaks guix system reconfigure. In particular, after reconfiguring,

> shepherd doesn’t know about the updated versions of services.

>

> The usual output below is missing; after reverting the commit it’s

> fine again.

>

> guix system: loading new services: …

> To complete the upgrade, run 'herd restart SERVICE' to stop,

> upgrade, and restart each service that was not automatically restarted.

> shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?).

> shepherd: Service user-homes has been started.

> shepherd: Service term-auto could not be started.

> bootloader successfully installed on '/dev/sda’

>

> I see that some system tests for “guix system reconfigure” were added

> after this change. Might I suggest adding them before the change next

> time around, and making sure they pass both before and after?

>

> Cheers

> Robert

> Yes, it seems it does!

> Great :)

>

> CC'ing Chris and Dave since I don't have write access -- can we

> fast-track #36880 into master? I'd consider this to be a high-priority

> bug fix.

>

> Regards,

> Jakob

> The patch made it into master as 1db6f137d; thanks to Danny for signing

> off on it. Should we close this?

> I made the mistake of rebooting my machine after I first got this error, I

> thought perhaps it was benign. But when it came back up I was dropped to a

> GRUB rescue shell with some error about "grub_file_filters" being an unknown

> symbol.

> When running grub commands like "insmod normal" would just repeat the error

> or say command not found.

> The only way I could think to repair it was to run the Guix install disk,

> mount my partitions, and do another "guix init" which allows me to boot into

> my machine again. However, when I run "guix pull" and then perform a

> reconfigure I still keep seeing the same line:

> shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?)

> ison <ison@airmail.cc> writes:

>

>> I made the mistake of rebooting my machine after I first got this

>> error, I thought perhaps it was benign. But when it came back up I

>> was dropped to a GRUB rescue shell with some error about

>> "grub_file_filters" being an unknown symbol.

>

> This eems unrelated. The problem sounds like GRUB and its modules

> aren’t found for some reason.

>> When running grub commands like "insmod normal" would just repeat the error

>> or say command not found.

>> The only way I could think to repair it was to run the Guix install disk,

>> mount my partitions, and do another "guix init" which allows me to boot into

>> my machine again. However, when I run "guix pull" and then perform a

>> reconfigure I still keep seeing the same line:

>> shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?)

>

> I reconfigured a workstation yesterday and also saw this line. It does

> look like an error, but it seems to be completely harmless. I could

> boot juts fine. I suppose that’s just the part where new service

> definitions are loaded.

>

> The problem you’re seeing is unrelated to this output.

> ison -- I'm very sorry that you've had this experience. Would you be

> willing to share the 'bootloader' field of your operating system

> configuration so I can look into this?

> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:

>

>> Great :)

>>

>> CC'ing Chris and Dave since I don't have write access -- can we

>> fast-track #36880 into master? I'd consider this to be a high-priority

>> bug fix.

>>

>> Regards,

>> Jakob

>

> The patch made it into master as 1db6f137d; thanks to Danny for signing

> off on it. Should we close this?