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

Previous Next

Full log

View this message in rfc822 format

From: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
To: 22624 <at> debbugs.gnu.org
Cc: beebe <at> math.utah.edu
Subject: bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd
Date: Wed, 10 Feb 2016 14:57:53 -0700

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: beebe <at> math.utah.edu  -
- 155 S 1400 E RM 233                       beebe <at> acm.org  beebe <at> computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.