Hi,
Maxim Cournoyer <maxim.courno...@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’.
