I have had a look at this as part of the Cambridge BSP 2019-03-09 I am able to reproduce this 'bug', on multiple architectures the following is copy/paste from buster on my AMD64 laptop :-p
Simply running the test by hand Assuming you have a working / reliable resolver / untainted cache then the command succeeds: ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -d root IPv6 root a.root-servers.n Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -w -d root IPv6 root a.root-servers.net Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -a -d root IPv6 root Wed Aug 28 21:30 - 21:40 (00:10) a.root-servers.net wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 causing a failure can be done simply by unplugging the machine from the network, thus... ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -d root IPv6 root dns-server Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -w -d root IPv6 root dns-server Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 /util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -a -d root IPv6 root Wed Aug 28 21:30 - 21:40 (00:10) dns-server wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 From this I conclude that the test itself is poor - it is assuming that there is a consistently good network / resolver for the duration of the test, something that can not be assumed to always be true. Theoretically glitches can happen anywhere, at any time. Question. What is the purpose of these 3 specific tests? If we are confirming that 'last' is formatting output in the manor specified by the switches then the tests are successful: the reported output may contain EITHER a.root-servers.net XOR dns-server If we are testing that the lookup has happened then it is perfectly acceptable that it will not be possible due to a transitory network failure. this does not mean that last itself is not working correctly only that this test did not PASS (i.e. !PASS is not the same as FAIL) Maybe remove/disable the test, or add retries? Maybe add detection for a timeout failure and simply return a different value to warn about this?
signature.asc
Description: OpenPGP digital signature
