'guix system reconfigure' does not reload Shepherd services

Done

Details

6 participants

Alex Sassmannshausen
ison
Ludovic Courtès
Ricardo Wurmus
Robert Vollmert
Jakob L. Kreuze

Owner: unassigned

Submitted by: Robert Vollmert

Severity: important

Robert Vollmert wrote on 31 Jul 2019 18:18

guix system reconfigure broken

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

Message-ID:E4A38AEA-BAC9-41D0-9164-A9C7487BB4B8@vllmrt.net

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

Jakob L. Kreuze wrote on 31 Jul 2019 18:45

Recipients:(name . Robert Vollmert)(address . rob@vllmrt.net)

Message-ID:87wofycfuq.fsf@sdf.lonestar.org

Hi Robert,

Robert Vollmert <rob@vllmrt.net> writes:

Toggle quote (12 lines)> 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?

Toggle quote (4 lines)

> 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?

Sure. My apologies for not having the foresight to do that.

Regards,

Jakob

Robert Vollmert wrote on 31 Jul 2019 19:06

Recipients:(name . Jakob L. Kreuze)(address . zerodaysfordays@sdf.lonestar.org)

Message-ID:0D1F3165-BE55-42D8-98D9-364CB4904A0E@vllmrt.net

Toggle quote (19 lines)> 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?

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.

Toggle quote (4 lines)

> And is the line regarding

> bootloader installation also missing from 'guix system reconfigure'

> post-5c8c8c455?

I still get a bootloader line.

Cheers

Robert

Jakob L. Kreuze wrote on 31 Jul 2019 20:16

Recipients:(name . Robert Vollmert)(address . rob@vllmrt.net)

Message-ID:87k1bycbn8.fsf@sdf.lonestar.org

Hi Robert,

Robert Vollmert <rob@vllmrt.net> writes:

Toggle quote (11 lines)> 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?

Toggle quote (2 lines)

> I still get a bootloader line.

Great -- thanks for checking that for me!

Regards,

Jakob

Robert Vollmert wrote on 1 Aug 2019 10:30

Recipients:(name . Jakob L. Kreuze)(address . zerodaysfordays@sdf.lonestar.org)

Message-ID:AF85F3A1-9899-4F5C-AE81-42A52DE71386@vllmrt.net

Toggle quote (20 lines)> 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?

Yes, it seems it does!

Alex Sassmannshausen wrote on 1 Aug 2019 11:21

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

Message-ID:875znhi6lh.fsf@gmail.com

Thanks for reporting this, I experienced the same issue but blamed it on

my own infrastructure instead!

Good to hear it's resolved now.

Alex

Robert Vollmert <rob@vllmrt.net> writes:

Toggle quote (26 lines)> 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

Jakob L. Kreuze wrote on 1 Aug 2019 16:10

Recipients:(name . Robert Vollmert)(address . rob@vllmrt.net)

Message-ID:871ry59dsw.fsf@sdf.lonestar.org

Robert Vollmert <rob@vllmrt.net> writes:

Toggle quote (2 lines)

> 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

Jakob L. Kreuze wrote on 2 Aug 2019 17:11

Recipients:(name . Robert Vollmert)(address . rob@vllmrt.net)

Message-ID:87lfwb1u1o.fsf@sdf.lonestar.org

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

Toggle quote (9 lines)

> 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?

Regards,

Jakob

ison wrote on 5 Aug 2019 12:07

Recipients:(name . Jakob L. Kreuze)(address . zerodaysfordays@sdf.lonestar.org)

Message-ID:20190805100741.uh5ijas6tjw4efut@cf0

On Fri, Aug 02, 2019 at 11:11:31AM -0400, Jakob L. Kreuze wrote:

Toggle quote (3 lines)

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

> off on it. Should we close this?

I'm still experiencing this issue. "guix describe" shows that I'm using
commit 35600cd which should be newer than the fix.

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 (?))) # ?) ?)

I've tried this on several occasions over the last few days with different
commits following the supposed fix, and it still keeps doing the same thing,
and every time I follow the reconfigure with a reboot GRUB is broken again.

Ricardo Wurmus wrote on 5 Aug 2019 13:47

Recipients:(name . ison)(address . ison@airmail.cc)

Message-ID:87r25zzvdw.fsf@elephly.net

ison <ison@airmail.cc> writes:

Toggle quote (5 lines)

> 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.

Toggle quote (8 lines)

> 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.

Ricardo

Jakob L. Kreuze wrote on 5 Aug 2019 16:59

Recipients:(name . ison)(address . ison@airmail.cc)

Message-ID:87a7cnzmhe.fsf@sdf.lonestar.org

Hi ison and Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (10 lines)> 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.

It is unrelated to this specific issue, but it still does sound like my

patch is the source of the problem. Would you be willing to open a

separate ticket for tracking this, ison?

Toggle quote (15 lines)>> 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.

Yes, this output is normal. Shepherd loads service files by evaluating

Scheme expressions. I could have sworn that 'guix system reconfigure'

showed the same line prior to my patch.

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?

Regards,

Jakob

ison wrote on 6 Aug 2019 04:55

Recipients:(name . Jakob L. Kreuze)(address . zerodaysfordays@sdf.lonestar.org)

Message-ID:20190806025554.vl65jfdvoo7elazq@cf0

On Mon, Aug 05, 2019 at 10:59:57AM -0400, Jakob L. Kreuze wrote:

Toggle quote (4 lines)

> 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?

Thanks for taking an interest. Here is the new bug report:

https://issues.guix.gnu.org/issue/36942

Please let me know if there's any other information or testing I

can do to help figure it out.

Ludovic Courtès wrote on 23 Aug 2019 14:54

control message for bug #36878

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

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

severity 36878 important

quit

Ludovic Courtès wrote on 23 Aug 2019 14:55

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

Message-ID:878srk6nys.fsf@gnu.org

retitle 36878 'guix system reconfigure' does not reload Shepherd services

quit

Ludovic Courtès wrote on 23 Aug 2019 14:55

Re: bug#36878: guix system reconfigure broken

Recipients:(name . Jakob L. Kreuze)(address . zerodaysfordays@sdf.lonestar.org)

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

Hello,

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

Toggle quote (14 lines)> 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?

I gather that this particular issue is fixed, so closing the bug now!

Ludo’.

Closed

Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it

mumi current 36878

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

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