Hi, Ludovic Courtès <[email protected]> writes:
> Hi, > > Maxim Cournoyer <[email protected]> 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
