
#15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I suspect that this is due to our use of Docker in the CircleCI infrastructure as I am unable to reproduce this under a Fedora VM. I have SSH'd into the CircleCI build machine and tried running `getGroupEntryForName` under `strace`. The relevant bit appears to be: {{{ openat(AT_FDCWD, "/lib64/libpcre2-8.so.0", 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 !\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=533864, ...}) = 0 mmap(NULL, 2626088, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f00d3f75000 mprotect(0x7f00d3ff6000, 2093056, PROT_NONE) = 0 mmap(0x7f00d41f5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x80000) = 0x7f00d41f5000 close(3) = 0 mprotect(0x7f00d41f5000, 4096, PROT_READ) = 0 mprotect(0x7f00d440c000, 4096, PROT_READ) = 0 --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} --- rt_sigreturn({mask=[]}) = 0 mprotect(0x7f00d4633000, 4096, PROT_READ) = 0 mprotect(0x7f00d4875000, 12288, PROT_READ) = 0 statfs("/sys/fs/selinux", 0x7ffc3c3aec40) = -1 ENOENT (No such file or directory) statfs("/selinux", 0x7ffc3c3aec40) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tr"..., 1024) = 351 read(3, "", 1024) = 0 close(3) = 0 access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or directory) munmap(0x7f00d6059000, 17156) = 0 rt_sigprocmask(SIG_BLOCK, [HUP USR1 USR2 PIPE ALRM CHLD TSTP URG VTALRM PROF WINCH IO], [], 8) = 0 getpid() = 9044 getpid() = 9044 getpid() = 9044 openat(AT_FDCWD, "/sys/fs/kdbus/0-system/bus", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0 setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) setsockopt(3, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0 getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) setsockopt(3, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0 connect(3, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 33) = -1 ENOENT (No such file or directory) getpid() = 9044 close(3) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(2, "getGroupEntryForName: ", 22getGroupEntryForName: ) = 22 write(2, "getGroupEntryForName: does not e"..., 64getGroupEntryForName: does not exist (No such file or directory)) = 64 write(2, "\n", 1 ) = 1 }}} The most interesting line of the above is {{{ connect(3, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 33) = -1 ENOENT (No such file or directory) }}} which suggests that `dbus` isn't running (which `ps` confirms). Moreover `/var/run/dbus` doesn't exist. However, strangely, `dnf` suggests that the `dbus` package is indeed installed. Moreover, `systemctl status fails: {{{ $ sudo systemctl status Failed to connect to bus: No such file or directory }}} This is somewhat expected given that this is a container and it explains why `dbus` wasn't started. The next question is why this testcase is calling for `dbus` at all. I do see a few mentions of `systemd` in the PAM configuration, although only as optional authentication steps. Perhaps more concerning is this in `/etc/nsswitch.conf`: {{{ passwd: sss files systemd shadow: files sss group: sss files systemd }}} Indeed removing the mentions of `systemd` from these lines allows the test to fail in the expected way: {{{ $ getGroupEntryForName.run/getGroupEntryForName getGroupEntryForName: getGroupEntryForName: does not exist (no such group) }}} It looks like we will need to modify `nsswitch.conf` to eliminate mentions of systemd while building the Docker image. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15230#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler