Stability of Hurd systems (was: shell account on hurd)

[Thomas Schwinge]

Hello Ralf!

On Thu, Oct 08, 2009 at 08:55:07PM +0200, Ralf Wildenhues wrote:
> * Thomas Schwinge wrote on Thu, Oct 08, 2009 at 08:46:45AM CEST:
> > Please try not to use flubber for things known to
> > destabilize the system (i.e., procedures that are known to cause a crash,
> > etc.).  If you have a need for testing such things, you can get an
> > account on grubber.
> 
> To me, nothing is yet known to crash on Hurd.  :-)  Where can I find
> information about what others know?

Here, and there, and everywhere -- meaning it's very scattered throughout
<http://hurd.gnu.org/> (the Open Issues, for example), the trackers at
the Savannah Hurd group, mailing list archives, IRC logs, developers'
minds, etc.  We are working on consolidating all this, and fixing such
issues, but it's a slow process -- lack of manpower, difficulties in
understanding complex systems and their interactions, etc.

It mainly boils down to resource exhaustion in the Mach microkernel --
caused by using up all memory, overflowing fixed-size in-kernel data
structures, creating 100.000 threads, and so on.  This may be caused
either by programming errors in the Hurd servers, in glibc, in Mach
itself, or simply due to the user doing ``stupid'' things (intentionally,
or not).  The kernel doesn't have a proper resource accounting system,
and doesn't (can't) prevent you from doing things you shouldn't be doing
-- (indirectly) allocating too many resources so that the kernel will
knock out itself.  Another common method for tearing down the system is
to get the (root) filesystem server into an inconsistent / dead-locked
state.  Eric Blake just discovered such a thing:
<http://lists.gnu.org/archive/html/bug-hurd/2009-10/msg00034.html>.

So, to sum it up: just do your work, and if you notice strange things
then please report them.


Regards,
 Thomas

signature.asc
Description: Digital signature