bug#30298: core-updates: Failure to find the guixbuild group

bug#30298: core-updates: Failure to find the guixbuild group

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

I updated my Guix installation on a Debian system to the latest
core-updates (8b9dbdf36fa89b7eb02).

After restarting the guix-daemon, anything requiring a build fails like
this:

# guix package --rollback
guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist

But:

# grep guixbuild /etc/group
guixbuild:x:999:guixbuilder01,guixbuilder02,guixbuilder03,guixbuilder04,guixbuilder05,guixbuilder06,guixbuilder07,guixbuilder08,guixbuilder09,guixbuilder10

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#30298: core-updates: Failure to find the guixbuild group

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 6326 bytes --]

Here is the strace of guix-daemon:

strace: Process 21446 attached
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
accept(3, {sa_family=AF_UNIX}, [128->2]) = 4
fcntl(4, F_GETFD)                       = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = -1 EOPNOTSUPP (Operation not supported)
setsockopt(4, SOL_TCP, TCP_QUICKACK, [1], 4) = -1 EOPNOTSUPP (Operation not supported)
getsockopt(4, SOL_SOCKET, SO_PEERCRED, {pid=21666, uid=1000, gid=1000}, [12]) = 0
write(2, "accepted connection from pid 216"..., 46) = 46
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f49fcf761d0) = 21672
strace: Process 21672 attached
[pid 21446] close(4 <unfinished ...>
[pid 21672] set_robust_list(0x7f49fcf761e0, 24 <unfinished ...>
[pid 21446] <... close resumed> )       = 0
[pid 21672] <... set_robust_list resumed> ) = 0
[pid 21446] select(4, [3], NULL, NULL, NULL <unfinished ...>
[pid 21672] close(3)                    = 0
[pid 21672] setsid()                    = 21672
[pid 21672] rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, {sa_handler=0x408f90, sa_mask=~[KILL STOP RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, 8) = 0
[pid 21672] rt_sigaction(SIGIO, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
[pid 21672] getpid()                    = 21672
[pid 21672] fcntl(4, F_SETOWN, 21672)   = 0
[pid 21672] fcntl(4, F_GETFL)           = 0x2 (flags O_RDWR)
[pid 21672] fcntl(4, F_SETFL, O_RDWR|O_ASYNC) = 0
[pid 21672] read(4, "cxin\0\0\0\0", 32768) = 8
[pid 21672] write(4, "oixd\0\0\0\0a\1\0\0\0\0\0\0", 16) = 16
[pid 21672] read(4, "a\1\0\0\0\0\0\0", 32768) = 8
[pid 21672] --- SIGIO {si_signo=SIGIO, si_code=SI_KERNEL} ---
[pid 21672] read(4, "\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0", 32768) = 16
[pid 21672] rt_sigaction(SIGIO, {sa_handler=0x4096f0, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, {sa_handler=SIG_IGN, sa_mask=~[KILL STOP RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, 8) = 0
[pid 21672] select(5, [4], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
[pid 21672] lstat("/gnu/store", {st_dev=makedev(254, 0), st_ino=261483, st_mode=S_IFDIR|S_ISVTX|0775, st_nlink=812, st_uid=0, st_gid=999, st_blksize=4096, st_blocks=2864, st_size=1462272, st_atime=2018-01-30T05:08:01-0500.005440398, st_mtime=2018-01-30T21:58:20-0500.717328223, st_ctime=2018-01-30T21:58:20-0500.717328223}) = 0
[pid 21672] getuid()                    = 0
[pid 21672] statfs("/gnu/store", {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=2370105, f_bfree=678352, f_bavail=552196, f_files=610800, f_ffree=439747, f_fsid={val=[1197410366, 3135970965]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
[pid 21672] lstat("/gnu/store/.links", {st_dev=makedev(254, 0), st_ino=261484, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=29704, st_size=15196160, st_atime=2018-01-30T05:09:07-0500.734306527, st_mtime=2018-01-30T21:58:20-0500.657327505, st_ctime=2018-01-30T21:58:20-0500.657327505}) = 0
[pid 21672] lstat("/var/guix/profiles", {st_dev=makedev(254, 0), st_ino=261476, st_mode=S_IFDIR|0755, st_nlink=3, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2018-01-30T05:07:50-0500.201299582, st_mtime=1969-12-31T19:00:01-0500, st_ctime=2016-01-17T02:42:03-0500.994173793}) = 0
[pid 21672] lstat("/var/guix/temproots", {st_dev=makedev(254, 0), st_ino=261481, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2018-01-30T05:08:00-0500.989440189, st_mtime=2018-01-30T21:58:39-0500.313550723, st_ctime=2018-01-30T21:58:39-0500.313550723}) = 0
[pid 21672] lstat("/var/guix/db", {st_dev=makedev(254, 0), st_ino=261469, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2017-12-06T11:13:50-0500.709588501, st_mtime=2018-01-30T21:59:11-0500.449935220, st_ctime=2018-01-30T21:59:11-0500.449935220}) = 0
[pid 21672] lstat("/var/guix/gcroots", {st_dev=makedev(254, 0), st_ino=261474, st_mode=S_IFDIR|0755, st_nlink=3, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2018-01-30T05:07:50-0500.201299582, st_mtime=2017-07-24T03:33:04-0400.151020803, st_ctime=2017-07-24T03:33:04-0400.151020803}) = 0
[pid 21672] getuid()                    = 0
[pid 21672] lstat("/var/guix/profiles/per-user", {st_dev=makedev(254, 0), st_ino=261477, st_mode=S_IFDIR|S_ISVTX|0777, st_nlink=4, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2018-01-30T21:57:51-0500.636980272, st_mtime=2016-01-17T03:24:24-0500.763756302, st_ctime=2018-01-30T21:59:58-0500.434480564}) = 0
[pid 21672] chmod("/var/guix/profiles/per-user", 01777) = 0
[pid 21672] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 21672] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 21672] close(3)                    = 0
[pid 21672] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 21672] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 21672] close(3)                    = 0
[pid 21672] futex(0x7f49fbe86190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
[pid 21672] rt_sigaction(SIGIO, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, {sa_handler=0x4096f0, sa_mask=~[KILL STOP RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, 8) = 0
[pid 21672] write(4, "ptxc\0\0\0\0E\0\0\0\0\0\0\0the group `guixb"..., 96) = 96
[pid 21672] exit_group(0)               = ?
[pid 21672] +++ exited with 0 +++
<... select resumed> )                  = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21672, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
wait4(-1, NULL, WNOHANG, NULL)          = 21672
wait4(-1, NULL, WNOHANG, NULL)          = -1 ECHILD (No child processes)
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
select(4, [3], NULL, NULL, NULL

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#30298: core-updates: Failure to find the guixbuild group

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 3263 bytes --]

On Tue, Jan 30, 2018 at 10:03:34PM -0500, Leo Famulari wrote:
> [pid 21672] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
> [pid 21672] close(3)                    = 0
> [pid 21672] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> [pid 21672] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
> [pid 21672] close(3)                    = 0
> [pid 21672] futex(0x7f49fbe86190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> [pid 21672] rt_sigaction(SIGIO, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, {sa_handler=0x4096f0, sa_mask=~[KILL STOP RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, 8) = 0
> [pid 21672] write(4, "ptxc\0\0\0\0E\0\0\0\0\0\0\0the group `guixb"..., 96) = 96
> [pid 21672] exit_group(0)               = ?
> [pid 21672] +++ exited with 0 +++
> <... select resumed> )                  = ? ERESTARTNOHAND (To be restarted if no handler)
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21672, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
> wait4(-1, NULL, WNOHANG, NULL)          = 21672
> wait4(-1, NULL, WNOHANG, NULL)          = -1 ECHILD (No child processes)
> rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
> select(4, [3], NULL, NULL, NULL

On GuixSD instead of Debian, also using core-updates, it instead
proceeds successfully like this:

52 [pid 22286] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
53 [pid 22286] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = 0
54 [pid 22286] sendto(3, "\2\0\0\0\f\0\0\0\6\0\0\0group\0", 18, MSG_NOSIGNAL, NULL, 0) = 18
55 [pid 22286] poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
56 [pid 22286] recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="", iov_len=6}, {iov_base="", iov_len=8}], msg_iovlen=2, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_C     LOEXEC) = 0
57 [pid 22286] close(3)                    = 0
58 [pid 22286] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
59 [pid 22286] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = 0
60 [pid 22286] sendto(3, "\2\0\0\0\2\0\0\0\n\0\0\0guixbuild\0", 22, MSG_NOSIGNAL, NULL, 0) = 22
61 [pid 22286] poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
62 [pid 22286] read(3, "\2\0\0\0\377\377\377\377\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0", 24) = 24
63 [pid 22286] close(3)                    = 0
64 [pid 22286] open("/etc/group", O_RDONLY|O_CLOEXEC) = 3
65 [pid 22286] fstat(3, {st_dev=makedev(8, 1), st_ino=524529, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=550, st_atime=1517333161 /* 2018-01-     30T12:26:01.702640653-0500 */, st_atime_nsec=702640653, st_mtime=1515043935 /* 2018-01-04T00:32:15.108027808-0500 */, st_mtime_nsec=108027808, st_ctime=1515043935 /* 2018-01-04T00:32:15.1     32027927-0500 */, st_ctime_nsec=132027927}) = 0
66 [pid 22286] read(3, "root:x:0:\nwheel:x:999:leo\nusers:"..., 4096) = 550
67 [pid 22286] close(3)                    = 0

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#30298: core-updates: Failure to find the guixbuild group

[Ludovic Courtès]

Hey!

Leo Famulari <leo@famulari.name> skribis:

> I updated my Guix installation on a Debian system to the latest
> core-updates (8b9dbdf36fa89b7eb02).
>
> After restarting the guix-daemon, anything requiring a build fails like
> this:
>
> # guix package --rollback
> guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist

[...]

> [pid 21672] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> [pid 21672] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
> [pid 21672] close(3)                    = 0
> [pid 21672] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> [pid 21672] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
> [pid 21672] close(3)                    = 0
> [pid 21672] futex(0x7f49fbe86190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> [pid 21672] rt_sigaction(SIGIO, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, {sa_handler=0x4096f0, sa_mask=~[KILL STOP RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f49fb8f2250}, 8) = 0
> [pid 21672] write(4, "ptxc\0\0\0\0E\0\0\0\0\0\0\0the group `guixb"..., 96) = 96
> [pid 21672] exit_group(0)               = ?
> [pid 21672] +++ exited with 0 +++

I suppose it works if you start nscd on this Debian machine (as is the
case on GuixSD), right?

The question is why isn’t guix-daemon falling back to loading
libnss_files and reading /etc/groups directly.

How is this guix-daemon built?  What libc is it linked against?
Does /etc/nsswitch.conf exist and what does it contain?

On my GuixSD it seems to work as expected:

--8<---------------cut here---------------start------------->8---
$ /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/bin/getent group guixbuild
guixbuild:x:30000:guixbuilder01,guixbuilder02,guixbuilder03,guixbuilder04,guixbuilder05,guixbuilder06,guixbuilder07,guixbuilder08,guixbuilder09,guixbuilder10
$ sudo herd stop nscd
Service nscd has been stopped.
$ /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/bin/getent group guixbuild
guixbuild:x:30000:guixbuilder01,guixbuilder02,guixbuilder03,guixbuilder04,guixbuilder05,guixbuilder06,guixbuilder07,guixbuilder08,guixbuilder09,guixbuilder10
$ strace /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/bin/getent group guixbuild

[...]

socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=207, ...}) = 0
read(3, "group:\tcompat [NOTFOUND=return] "..., 4096) = 207
read(3, "", 4096)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\"\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0555, st_size=56928, ...}) = 0
mmap(NULL, 2168632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f420943d000
mprotect(0x7f4209448000, 2093056, PROT_NONE) = 0
mmap(0x7f4209647000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7f4209647000
mmap(0x7f4209649000, 22328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4209649000
close(3)                                = 0
mprotect(0x7f4209647000, 4096, PROT_READ) = 0
open("/etc/group", O_RDONLY|O_CLOEXEC)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=666, ...}) = 0
read(3, "root:x:0:\nwheel:x:999:ludo\nusers"..., 4096) = 666
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
write(1, "guixbuild:x:30000:guixbuilder01,"..., 158guixbuild:x:30000:guixbuilder01,guixbuilder02,guixbuilder03,guixbuilder04,guixbuilder05,guixbuilder06,guixbuilder07,guixbuilder08,guixbuilder09,guixbuilder10
) = 158
exit_group(0)                           = ?
+++ exited with 0 +++
--8<---------------cut here---------------end--------------->8---

Ludo’.

bug#30298: core-updates: Failure to find the guixbuild group

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Wed, Jan 31, 2018 at 11:38:35PM +0100, Ludovic Courtès wrote:
> I suppose it works if you start nscd on this Debian machine (as is the
> case on GuixSD), right?

Yes, `apt-get install nscd` does everything necessary to set up and
start nscd, and then guix-daemon works.

> The question is why isn’t guix-daemon falling back to loading
> libnss_files and reading /etc/groups directly.
> 
> How is this guix-daemon built?  What libc is it linked against?
> Does /etc/nsswitch.conf exist and what does it contain?

This guix-daemon is based on core-updates commit 76ef53eb828 (gnu:
glslang: Update to commit b5b084624), on x86_64-linux.

It's linked against
/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c.

nsswitch.conf looks like this:

$ ls -l /etc/nsswitch.conf 
-rw-r--r-- 1 root root 529 Jun 13  2017 /etc/nsswitch.conf
$ cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#30298: core-updates: Failure to find the guixbuild group

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Jan 31, 2018 at 11:38:35PM +0100, Ludovic Courtès wrote:
>> I suppose it works if you start nscd on this Debian machine (as is the
>> case on GuixSD), right?
>
> Yes, `apt-get install nscd` does everything necessary to set up and
> start nscd, and then guix-daemon works.

OK.  (Note that running nscd is recommended anyway when using Guix on
foreign distros anyway.)

>> The question is why isn’t guix-daemon falling back to loading
>> libnss_files and reading /etc/groups directly.
>> 
>> How is this guix-daemon built?  What libc is it linked against?
>> Does /etc/nsswitch.conf exist and what does it contain?
>
> This guix-daemon is based on core-updates commit 76ef53eb828 (gnu:
> glslang: Update to commit b5b084624), on x86_64-linux.

If you stop nscd again and “strace -f” guix-daemon entirely, can you
check if it ever tries to open libnss_*?

Ludo’.

bug#30298: core-updates: Failure to find the guixbuild group

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

On Wed, Jan 31, 2018 at 11:38:35PM +0100, Ludovic Courtès wrote:
> The question is why isn’t guix-daemon falling back to loading
> libnss_files and reading /etc/groups directly.

This is my first time poking around this part of the system so I'm not
sure what to expect. Reading the manpage for nsswitch.conf led me to
believe that the libnss_* libraries would be found directly under /lib.
However, on my Debian systems, they are split up by architecture like
this:

$ find /lib -name "*libnss*"
./i386-linux-gnu/libnss_compat-2.24.so
./i386-linux-gnu/libnss_dns-2.24.so
./i386-linux-gnu/libnss_nis.so.2
./i386-linux-gnu/libnss_nisplus.so.2
./i386-linux-gnu/libnss_nisplus-2.24.so
./i386-linux-gnu/libnss_hesiod-2.24.so
./i386-linux-gnu/libnss_files.so.2
./i386-linux-gnu/libnss_hesiod.so.2
./i386-linux-gnu/libnss_files-2.24.so
./i386-linux-gnu/libnss_compat.so.2
./i386-linux-gnu/libnss_dns.so.2
./i386-linux-gnu/libnss_nis-2.24.so
./x86_64-linux-gnu/libnss_compat-2.24.so
./x86_64-linux-gnu/libnss_mdns.so.2
./x86_64-linux-gnu/libnss_dns-2.24.so
./x86_64-linux-gnu/libnss_nis.so.2
./x86_64-linux-gnu/libnss_mdns_minimal.so.2
./x86_64-linux-gnu/libnss_nisplus.so.2
./x86_64-linux-gnu/libnss_nisplus-2.24.so
./x86_64-linux-gnu/libnss_mdns4_minimal.so.2
./x86_64-linux-gnu/libnss_mdns6.so.2
./x86_64-linux-gnu/libnss_hesiod-2.24.so
./x86_64-linux-gnu/libnss_files.so.2
./x86_64-linux-gnu/libnss_mdns4.so.2
./x86_64-linux-gnu/libnss_hesiod.so.2
./x86_64-linux-gnu/libnss_files-2.24.so
./x86_64-linux-gnu/libnss_compat.so.2
./x86_64-linux-gnu/libnss_dns.so.2
./x86_64-linux-gnu/libnss_mdns6_minimal.so.2
./x86_64-linux-gnu/libnss_nis-2.24.so

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#30298: core-updates: Failure to find the guixbuild group

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Wed, Jan 31, 2018 at 11:52:23PM +0100, Ludovic Courtès wrote:
> > This guix-daemon is based on core-updates commit 76ef53eb828 (gnu:
> > glslang: Update to commit b5b084624), on x86_64-linux.
> 
> If you stop nscd again and “strace -f” guix-daemon entirely, can you
> check if it ever tries to open libnss_*?

It never does. The strace log I posted previously is the complete log:

https://debbugs.gnu.org/cgi/bugreport.cgi?att=0;bug=30298;msg=8

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#30298: core-updates: Failure to find the guixbuild group

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Jan 31, 2018 at 11:52:23PM +0100, Ludovic Courtès wrote:
>> > This guix-daemon is based on core-updates commit 76ef53eb828 (gnu:
>> > glslang: Update to commit b5b084624), on x86_64-linux.
>> 
>> If you stop nscd again and “strace -f” guix-daemon entirely, can you
>> check if it ever tries to open libnss_*?
>
> It never does. The strace log I posted previously is the complete log:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?att=0;bug=30298;msg=8

I think you attached strace to the running guix-daemon process here.
What I meant is that we should trace it from the beginning of its
execution (so either run it by hand or modify the .service file to run
“strace -f guix-daemon …”.)

Ludo’.

bug#30298: core-updates: Failure to find the guixbuild group

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Thu, Feb 01, 2018 at 12:28:32AM +0100, Ludovic Courtès wrote:
> I think you attached strace to the running guix-daemon process here.
> What I meant is that we should trace it from the beginning of its
> execution (so either run it by hand or modify the .service file to run
> “strace -f guix-daemon …”.)

Oh, right. The issue is that, starting in glibc 2.26, libnss_compat is
not built unless the glibc build is configured with
--enable-obsolete-nsl:

"If glibc was configured without --enable-obsolete-nsl the libnss_compat
library will not be built. If the library is not built, it may still be
found during testing if dl_open searches the default host library
directories."

https://sourceware.org/glibc/wiki/Release/2.26#Architecture-independent

In fact, I already noticed this and worked around it for another package
without really understanding what it meant:

https://bugs.gnu.org/29970
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=0f7db1d320fd26a11854c8d7f404a3cf16eb3fbc

And we can see the core-updates guix-daemon try and fail to open
libnss_compat.so:

308 connect(5, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
309 close(5)                                = 0
310 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
311 connect(5, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
312 close(5)                                = 0
313 open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 5
314 fstat(5, {st_dev=makedev(252, 1), st_ino=1047888, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=529, st_atime=2018-01-31T17:17:26-0500.3612163    70, st_mtime=2017-06-13T03:33:07-0400.283237951, st_ctime=2017-06-13T03:33:07-0400.283237951}) = 0
315 read(5, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 529
316 read(5, "", 4096)                       = 0
317 close(5)                                = 0
318 openat(AT_FDCWD, "/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#30298: core-updates: Failure to find the guixbuild group

[Ludovic Courtès]

Hello,

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Feb 01, 2018 at 12:28:32AM +0100, Ludovic Courtès wrote:
>> I think you attached strace to the running guix-daemon process here.
>> What I meant is that we should trace it from the beginning of its
>> execution (so either run it by hand or modify the .service file to run
>> “strace -f guix-daemon …”.)
>
> Oh, right. The issue is that, starting in glibc 2.26, libnss_compat is
> not built unless the glibc build is configured with
> --enable-obsolete-nsl:

[...]

> And we can see the core-updates guix-daemon try and fail to open
> libnss_compat.so:

Yes, but in the trace I gave, it then goes on dlopening libnss_files,
which is the NSS module to read databases like /etc/groups directly, and
succeeds:

--8<---------------cut here---------------start------------->8---
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=207, ...}) = 0
read(3, "group:\tcompat [NOTFOUND=return] "..., 4096) = 207
read(3, "", 4096)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\"\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0555, st_size=56928, ...}) = 0
mmap(NULL, 2168632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f420943d000
mprotect(0x7f4209448000, 2093056, PROT_NONE) = 0
mmap(0x7f4209647000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7f4209647000
mmap(0x7f4209649000, 22328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4209649000
close(3)                                = 0
mprotect(0x7f4209647000, 4096, PROT_READ) = 0
open("/etc/group", O_RDONLY|O_CLOEXEC)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=666, ...}) = 0
read(3, "root:x:0:\nwheel:x:999:ludo\nusers"..., 4096) = 666
--8<---------------cut here---------------end--------------->8---

The problem in your case is that /etc/nsswitch.conf has this:

--8<---------------cut here---------------start------------->8---
passwd:         compat
group:          compat
shadow:         compat
--8<---------------cut here---------------end--------------->8---

… meaning that it only tries libnss_compat, and fails if its missing.
If you replace these “compat” with “files”, I think it’ll work.

FWIW on GuixSD I have this:

--8<---------------cut here---------------start------------->8---
group:	compat [NOTFOUND=return] files
hosts:	files mdns_minimal [NOTFOUND=return] dns mdns
networks:	files dns [!UNAVAIL=return]
passwd:	compat [NOTFOUND=return] files
shadow:	compat [NOTFOUND=return] files
--8<---------------cut here---------------end--------------->8---

The nsswitch.conf on GuixSD is based on the defaults defined in glibc,
as noted in (gnu system nss).

I’m not sure what can be done on our side.  We already recommend
starting the nscd:

  https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Name-Service-Switch-1

Thoughts?

Ludo’.

bug#30298: core-updates: Failure to find the guixbuild group

[Leo Famulari]

On Thu, Feb 01, 2018 at 10:06:07AM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > And we can see the core-updates guix-daemon try and fail to open
> > libnss_compat.so:
> 
> Yes, but in the trace I gave, it then goes on dlopening libnss_files,
> which is the NSS module to read databases like /etc/groups directly, and
> succeeds:
> 
> --8<---------------cut here---------------start------------->8---
> connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
> close(3)                                = 0
> open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0444, st_size=207, ...}) = 0
> read(3, "group:\tcompat [NOTFOUND=return] "..., 4096) = 207
> read(3, "", 4096)                       = 0
> close(3)                                = 0
> openat(AT_FDCWD, "/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\"\0\0\0\0\0\0"..., 832) = 832
> fstat(3, {st_mode=S_IFREG|0555, st_size=56928, ...}) = 0
> mmap(NULL, 2168632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f420943d000
> mprotect(0x7f4209448000, 2093056, PROT_NONE) = 0
> mmap(0x7f4209647000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7f4209647000
> mmap(0x7f4209649000, 22328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4209649000
> close(3)                                = 0
> mprotect(0x7f4209647000, 4096, PROT_READ) = 0
> open("/etc/group", O_RDONLY|O_CLOEXEC)  = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=666, ...}) = 0
> read(3, "root:x:0:\nwheel:x:999:ludo\nusers"..., 4096) = 666
> --8<---------------cut here---------------end--------------->8---
> 
> The problem in your case is that /etc/nsswitch.conf has this:
> 
> --8<---------------cut here---------------start------------->8---
> passwd:         compat
> group:          compat
> shadow:         compat
> --8<---------------cut here---------------end--------------->8---
> 
> … meaning that it only tries libnss_compat, and fails if its missing.
> If you replace these “compat” with “files”, I think it’ll work.
> 
> FWIW on GuixSD I have this:
> 
> --8<---------------cut here---------------start------------->8---
> group:	compat [NOTFOUND=return] files
> hosts:	files mdns_minimal [NOTFOUND=return] dns mdns
> networks:	files dns [!UNAVAIL=return]
> passwd:	compat [NOTFOUND=return] files
> shadow:	compat [NOTFOUND=return] files
> --8<---------------cut here---------------end--------------->8---
> 
> The nsswitch.conf on GuixSD is based on the defaults defined in glibc,
> as noted in (gnu system nss).

Thanks for writing all this out, it's very educational!

> I’m not sure what can be done on our side.  We already recommend
> starting the nscd:
> 
>   https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Name-Service-Switch-1

In that case, I think the solution is for me to `apt-get install nscd`.

Closing :)