bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd

[Nelson H. F. Beebe]

I'm pleased to report successful builds, validations, and
installations of coreutils-8.25 on at least 72 of the 77 machines in
our lab running various flavors of Unix.

The one problematic system is GNU/Hurd, aka Debian GNU/Hurd
stretch/sid.  We ran Hurd on VMware/ESX for a couple of years, but it
was never stable, and crashed or hung every few hours.  Every such
failure requires a manual fsck on reboot, preventing automated
recovery.

Last summer, I moved Hurd to virt-manager + QEMU on my desktop, where
it has proved substantially more stable, sometimes staying up for many
days.

Debian GNU/Hurd has about 47,580 packages available in the Debian
apt-get system, so others have clearly done a lot of work on it.
There are major, and reasonably-current, packages like these available
via apt-get:

        /usr/bin/clang-3.6 --version
        Debian clang version 3.6.2-1 (tags/RELEASE_362/final) (based on LLVM 
3.6.2)
        Target: i386-pc--gnu
        Thread model: posix

        /usr/bin/gcc --version
        gcc (Debian 5.2.1-26) 5.2.1 20151125

        /bin/ls --version
        ls (GNU coreutils) 8.23

With builds of coreutils-8.25 at my site, the "make check" run ALWAYS
hangs Hurd, requiring a reboot and an fsck.

I've just made further experiments that confirm that the hang always
happens in the same place, about 60 seconds after starting this
command:

        $ make check
        ... lots of PASS reports, except FAIL in tests/misc/kill.sh and 
tests/split/filter.sh ...
        PASS: tests/split/b-chunk.sh
        PASS: tests/split/fail.sh
        PASS: tests/split/lines.sh
        line-bytes.sh: skipped test: this shell lacks ulimit support
        SKIP: tests/split/line-bytes.sh
        Timeout, server 192.168.122.66 not responding.

The default memory size is 1GB, but today I got the same results when
the VM was restarted with 2GB and with 8GB.

I have also run the "make check" in a console window, eliminating
possible network timeouts from the dataflow, with "top" running in a
separate xterm + ssh window, and got this output at the point of the
hang:

        # in console window
        SKIP: tests/split/line-bytes.sh
        no more room for vm_map_find_entry in 8022b080
        no more room for kmem_realloc in 8022b080
        /hurd/mach-defpage: panic: (default pager):

        # in simulataneous xterm window
        % top 
        top - 14:10:49 up 10 min,  8 users,  load average: 0.55, 1.33, 1.46
        Tasks:  74 total,   2 running,  69 sleeping,   0 stopped,   0 zombie
        %Cpu(s):  54.3 us,   0.0 sy,   0.0 ni,  45.7 id,   0.0 wa,   0.0 hi,   
0.0 si
        KiB Mem:   1900540 total,  1550052 used,   350488 free,        0 buffers
        KiB Swap:        0 total,        0 used,        0 free.     1792 cached 
Mem

          PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ 
COMMAND     
         1015 beebe     20   0  151616    144      0 S  0.0  0.0   0:00.02 
-bash       
         1081 beebe     30  10  150060    148      0 S  0.0  0.0   0:00.00 time 
       

The coreutils developers should probably not view this as a coreutils
bug, because Hurd has many oddities, and the pager-panic report
definitely suggests a kernel issue.

However, because coreutils has long been built and distributed on
Hurd, I thought it would be worthwhile to at least report my
experience, in the hope that other list members with GNU/Hurd systems
might be able to report their own result with the latest coreutils.

I unfortunately do not have any spare physical hardware on which to
run GNU/Hurd; my only access to it is on virtual machines.

My desktop is currently running 18 different VMs, on top of its CentOS
7 base operating system.  Apart from GNU/Hurd, all of the others have
been perfectly stable for 4 to 6 months of operation, so I think that
it is unlikely that the above failure is due to the virtual machine
environment.  There are two significant differences, however: the
others have virtual SATA disks and are 64-bit systems, whereas Hurd
supports only (virtual) EIDE disks, and is a 32-bit system.  Our
suspicions of the instability of Hurd on VMware/ESX have to do with
the EIDE virtual disk system, which may have been less well tested
than SATA.



-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------