bug#58205: reconfiguration stuck unless using '--no-grafts'

bug#58205: reconfiguration stuck unless using '--no-grafts'

[Maxim Cournoyer]

Hi,

While working on Berlin today from a chroot, and with --no-substitutes
used for guix-daemon, I wasn't able to complete the 'guix system
reconfigure' step; it'd hand on a read call (seen using strace):

--8<---------------cut here---------------start------------->8---
statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234, f_files=0, f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 152) = 152
read(14, "gmlo\0\0\0\0", 8)             = 8
read(14, "\276\0\0\0\0\0\0\0", 8)       = 8
read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
)     = 12
write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for guix-1.3.0-29.9e46320 ...
) = 48
read(14, "gmlo\0\0\0\0", 8)             = 8
read(14, "\255\0\0\0\0\0\0\0", 8)       = 8
read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
\)                = 5
read(14,
--8<---------------cut here---------------end--------------->8---

After passing --no-grafts to 'guix system reconfigure', it could
complete without any error.

-- 
Thanks,
Maxim

bug#58205: reconfiguration stuck unless using '--no-grafts'

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> While working on Berlin today from a chroot, and with --no-substitutes
> used for guix-daemon, I wasn't able to complete the 'guix system
> reconfigure' step; it'd hand on a read call (seen using strace):
>
> statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234, f_files=0, f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
> write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 152) = 152
> read(14, "gmlo\0\0\0\0", 8)             = 8
> read(14, "\276\0\0\0\0\0\0\0", 8)       = 8
> read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
> )     = 12
> write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for guix-1.3.0-29.9e46320 ...
> ) = 48
> read(14, "gmlo\0\0\0\0", 8)             = 8
> read(14, "\255\0\0\0\0\0\0\0", 8)       = 8
> read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
> \)                = 5
> read(14,

The build process is probably actually grafting things, and while doing
that it doesn’t output anything.  Thus it’s not surprising that the
client is stuck on read(2) waiting for data on the daemon socket.  It
might be that the grafting process is just taking a long time?

The way to debug that would be to run ‘sudo guix processes’, to identify
the build process and hand (the one that builds /gnu/store/kv1hg….drv in
the example above), and to strace that process.

HTH!

Ludo’.

bug#58205: reconfiguration stuck unless using '--no-grafts'

[Maxim Cournoyer]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> While working on Berlin today from a chroot, and with --no-substitutes
>> used for guix-daemon, I wasn't able to complete the 'guix system
>> reconfigure' step; it'd hand on a read call (seen using strace):
>>
>> statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096,
>> f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234,
>> f_files=0, f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]},
>> f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
>> write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 152) = 152
>> read(14, "gmlo\0\0\0\0", 8)             = 8
>> read(14, "\276\0\0\0\0\0\0\0", 8)       = 8
>> read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
>> )     = 12
>> write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for guix-1.3.0-29.9e46320 ...
>> ) = 48
>> read(14, "gmlo\0\0\0\0", 8)             = 8
>> read(14, "\255\0\0\0\0\0\0\0", 8)       = 8
>> read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
>> \)                = 5
>> read(14,
>
> The build process is probably actually grafting things, and while doing
> that it doesn’t output anything.  Thus it’s not surprising that the
> client is stuck on read(2) waiting for data on the daemon socket.  It
> might be that the grafting process is just taking a long time?

I think the CPU was idling at the time, per top.  Note that I was in a
chroot setup per info '(guix) Chrooting', with a pretty basic
'guix-daemon' invocation (non-chroot version), in case it could have
anything to do with it.

> The way to debug that would be to run ‘sudo guix processes’, to identify
> the build process and hand (the one that builds /gnu/store/kv1hg….drv in
> the example above), and to strace that process.

I'll do this next time I encounter this problem, thanks!

-- 
Maxim