After reading the configuration files, and writing out the hostnames to
be resolved to a temporary file, xntpd is meant to fork in order to do
the resolving. The final lines of the strace (copied by hand):
munmap(0x4000c000, 4096) = 0
sigaction(SIGCHLD, {0x804b950, (1,SA_NOMASK|0x10f010}, {SIG_DLF}) = 0
fork(
The strace stops there. Control-C doesn't stop it, and SysRq-K, SysRq-S,
and Sysrq-U print their various messages (SysRq: Emergency Sync and so
on), but without actually doing anything. I could change VTs, but
couldn't type on them, even on one running a bash shell niced to -20.
SysRq-E killed all processes except for init, and then the system
behaved normally.
xntpd had already forked once (successfully).
Commenting out the bits in the xntpd source code which set the
scheduling priority to SCHED_FIFO allowed the strace to continue
normally. I couldn't find a simple test case program to exhibit the same
problem, but a program which sets the scheduling to SCHED_FIFO, and then
calls fork(), hung at fork( when strace -f'd, but I could stop that with
Contorl-C.
The strace was done as root (for the SCHED_FIFO stuff to be allowed),
but the lockup still shouldn't have happened, and the sysrq keys should
have worked anyway, and the strace should have continued. Nicing the
strace to -20, (so that it had a higher priority than the xntpd program)
didn't help anything.
Results of SysRq-P (copied by hand):
EIP: 0023:[<4006b967>] ESP: 002b: bffff618 EFLAGS: 00000206
EAX: 00000000 EBX: 00000002 ECX: bdff4d0 EDX: bffff4c0
ESI: bffff798 EDI: 0806499c EBP: bffff63c DS: 002b ES: 002b
CR0: 8005003b CR2: 4009d090 CR3: 019c2000
Bootm lines of SysRq-T (copied by hand):
xntpd 14 T C1144000 6068 542 540 543
sig: 1 0000000000002000 0000000000000000 : X
xntpd -32 R current 0 543 542
sig: 0 0000000000000000 0000000000000000 : X
This is all repeatable.
Bradley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/