On release/2.33/master branch, i686 glibc configured with --enable-hardcoded-path-in-tests --enable-cet I got FAIL: nss/tst-reload2 [hjl@gnu-cfl-2 build-i686-linux]$ cat nss/tst-reload2.out tst-reload2.c:112: numeric comparison failure left: 5 (0x5); from: pw->pw_uid right: 1234 (0x4d2); from: 1234 error: tst-reload2.c:130: not true: pw->pw_uid != 2468 tst-reload2.c:136: numeric comparison failure left: 5 (0x5); from: pw->pw_uid right: 1234 (0x4d2); from: 1234 error: tst-reload2.c:146: not true: he != NULL error: 4 test failures [hjl@gnu-cfl-2 build-i686-linux]$
Do you have any IPv6 addresses configured on your system? Thanks.
(In reply to Florian Weimer from comment #1) > Do you have any IPv6 addresses configured on your system? Thanks. [hjl@gnu-cfl-2 ~]$ ifconfig eno1 eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1300 inet 192.168.1.17 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::b2a6:e6f1:de7a:da77 prefixlen 64 scopeid 0x20<link> ether 94:c6:91:a4:31:be txqueuelen 1000 (Ethernet) RX packets 11319 bytes 7199395 (6.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 8826 bytes 1601253 (1.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xb0b00000-b0b20000 [hjl@gnu-cfl-2 ~]$ ping fe80::b2a6:e6f1:de7a:da77 PING fe80::b2a6:e6f1:de7a:da77(fe80::b2a6:e6f1:de7a:da77) 56 data bytes ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument --- fe80::b2a6:e6f1:de7a:da77 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1010ms [hjl@gnu-cfl-2 ~]$ ping 192.168.1.17 PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data. 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.032 ms --- 192.168.1.17 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.032/0.032/0.032/0.000 ms [hjl@gnu-cfl-2 ~]$ There is no working IPv6. The same test works on master branch.
This is definitely odd. The test failures I've seen where on hosts where there were no IPv6 notworking interfaces. Maybe propagating IPv6 support into the container fails for some reason? But then support/test-container.c does not actually enter a network namespace, so this shouldn't be a problem.
I randomly see this failure on glibc master too. $cat tst-reload2.out tst-reload2.c:112: numeric comparison failure left: 5 (0x5); from: pw->pw_uid right: 1234 (0x4d2); from: 1234 error: tst-reload2.c:130: not true: pw->pw_uid != 2468 tst-reload2.c:136: numeric comparison failure left: 5 (0x5); from: pw->pw_uid right: 1234 (0x4d2); from: 1234 error: tst-reload2.c:146: not true: he != NULL error: 4 test failures
This is another random failure, it may be related to this issue. $ cat nss/tst-nss-files-hosts-long.out error: tst-nss-files-hosts-long.c:35: ahostsv4 failed error: 1 test failures
That always fails if there is no network.
Is this *only* i686? I see the he!=NULL error in 2.33 but not master, and not the other ones at all. Also, please try creating the file nss/tst-reload1.root/preclean.req - that will make sure there's nothing from a previous test interfering with this one. FYI the 5<->1234 errors indicate that the wrong service was used (test1 vs test2) and the he!=NULL one tests that libnss_files.so can be loaded after the chroot
They fail at random on both i686 and x86-64.
I'm getting the same output if running this sequence: $ cd <builddir> $ rm -f testroot.root/etc/nsswitch.conf $ make t=nss/tst-reload1 test PASS: nss/tst-reload1 $ cat testroot.root/etc/nsswitch.conf passwd: test2 group: test2 hosts: test2 $ make t=nss/tst-reload2 test tst-reload2.c:112: numeric comparison failure left: 5 (0x5); from: pw->pw_uid right: 1234 (0x4d2); from: 1234 error: tst-reload2.c:130: not true: pw->pw_uid != 2468 tst-reload2.c:136: numeric comparison failure left: 5 (0x5); from: pw->pw_uid right: 1234 (0x4d2); from: 1234 error: tst-reload2.c:146: not true: he != NULL error: 4 test failures $ cat testroot.root/etc/nsswitch.conf passwd: test2 group: test2 hosts: test2 According to tst-reload2.c and current nsswitch.conf, it is using pwd_table2, which is PWD_N (5, "test1"). According to the nss/tst-reload2.root/etc/nsswitch.conf, it should use PWD_N (1234, "test1") of pwd_table1. testroot.root/etc/nsswitch.conf was not synced by support/test-container.c as the size (40 bytes) and timestamp (in case of a fresh git clone) of nsswitch.conf files does not differ, but its content: nss/tst-reload1.root/etc/nsswitch.conf nss/tst-reload1.root/etc/nsswitch.conf2 nss/tst-reload2.root/etc/nsswitch.conf nss/tst-reload2.root/subdir/etc/nsswitch.conf You will also see fails if rerunning nss/tst-reload1 multiple times. See discussion on mailing-list: "[PATCH] Ensure that nsswitch.conf for nss/tst-reload[12] are really synced." https://sourceware.org/pipermail/libc-alpha/2021-March/123614.html Note: I have not checked if this is also the case for nss/tst-nss-files-hosts-long.
Commit 20bee7134801cc932ff87fac511289b92fc94944 fixes the 5<->1234 bug. I suspect to properly fix the he!=NULL error we'll have to switch from gethostbyname() to gethostent(), unless someone knows what makes gethostbyname() unpredictable.