[GHC] #15230: unix tests fail under CircleCI's fedora environment
GHC
ghc-devs at haskell.org
Fri Jun 15 13:59:31 UTC 2018
#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
More information about the ghc-tickets
mailing list