The runit package doesn't work, even its test suite doesn't finish.

Thomas Schwinge once was having a look at that, but this very report is just from his memory, and his memory is dim... The problem might either be a time stamping issue (which might be fixed by now) or it might be the select call failing issue we're seeing from time to time. Or something else.

?Harish Badrinath Originally answered by Samuel Thibault:

120->proc_dostop_request ( 138) = 0

Usual issue with rpctrace: it does not support fork().

I've checked a backtrace in gdb, got this:

 0x0105af6c in mach_msg_trap ()
   at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
1  0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140,
   timeout=1000020, notify=0) at msg.c:110
2  0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0,
   timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324
3  0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48
4  0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29
5  0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543

and main() shows up as:

 ->  iopause(x, 2 +haslog, &deadline, &now);

So it simply looks like the known "signals don't interrupt select" bug.