Linux Signal Handling and RT tasks broken?

Thomas Sailer (sailer@ife.ee.ethz.ch)
Sat, 4 Apr 1998 17:34:29 +0200 (MET DST)


I give up. I don't understand process termination.

Something seems very broken with either signal handling or process termination
for realtime processes. This is what happens to amp in 2.1.92 and all other
kernels I used (that is almost all) in 2.1.[89]x.

amp is a mpeg3 audio decoder. It fork()s 2 additional processes when it
starts. All 3 amp processes are in the same process group. amp does not
set any signal handlers, i.e. signals are in default state. One of those
3 processes has realtime scheduling and basically does the following:
for (;;) {
ioctl(fd, SNDCTL_DSP_GETOPTR, &x);
calculate
select (on writability of fd)
}

where fd is the file descriptor of the audio driver. The other 2
processes are mostly asleep. When started, it looks like the first half
of the text below, i.e. the ps axj output and the first three
/proc/x/status outputs. When I hit now CTRL-C on the controlling
terminal, as far as I understood signal handling, SIGINT should be
sent to the process group, i.e. to all three amp processes.
Since amp does not catch signals, all three amp processes should die.
They don't however. The annoying thing is that the realtime process
somehow starts to be always runnable, thus making the system unusable
as long as there is no realtime shell on a console around that would
allow to send an explicit signal (with kill) to it (which normally
terminates the process).

Note that the process has somehow left the loop depicted above, since
neither device driver ioctl nor dev drv poll are called anymore
(from a printk instrumented driver run, also /proc/x/stat shows 0 for
the eip and esp values)

>From a kernel with DEBUG_SIG = 1, it can be seen that the
SIGINT is correctly enqueued to all 3 amp processes
(and task->sigpending set), and afterwards the signal
is dequeued in all 3 amp processes, and sigpending reset to 0.
Interestingly, however, afterwards (from /proc/x/status), SIGINT
is set in the SigPnd mask, however sigpending is 0!!
(is this from arch/i386/kernel/signal.c:do_signal:676??)

>From SysRq-P, the kernel seems to be mostly in schedule(), at the
end of the goodness function.

This is i386, glibc 2.0.7. The same amp binary and the same audio
device driver (es1370) work flawlessly under 2.0.33.

Help!

Tom

PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
0 1 0 0 ? -1 S 0 0:03 init
1 2 1 1 ? -1 SW 0 0:00 (kflushd)
1 3 1 1 ? -1 SW< 0 0:00 (kswapd)
1 4 1 1 ? -1 SW 0 0:00 (kmod)
1 174 1 1 ? -1 SW 0 0:00 (rpciod)
1 24 24 24 ? -1 S 0 0:00 /sbin/kerneld
1 212 56 56 ? -1 S 2 0:00 /usr/sbin/atd
1 295 56 56 ? -1 S 0 0:00 rpc.mountd
1 190 190 190 ? -1 S 0 0:00 syslogd
1 223 223 223 ? -1 S 0 0:00 crond
1 234 234 234 ? -1 S 1 0:00 portmap
1 245 245 245 ? -1 S 0 0:00 /usr/sbin/snmpd -f
1 256 256 256 ? -1 S 0 0:00 inetd
1 267 267 267 ? -1 S 0 0:00 lpd
1 283 283 283 ? -1 S 0 0:00 sendmail: accepting connect
1 304 304 304 ? -1 S 0 0:00 rpc.nfsd
1 317 317 317 ? -1 S 0 0:00 gpm -t MouseSystems
1 328 328 328 ? -1 S 0 0:00 smbd -D
1 337 337 337 ? -1 S 0 0:00 nmbd -D
1 362 362 362 1 370 S 400 0:00 /bin/login -- hb9jnx
1 363 363 363 2 965 S 0 0:00 /bin/login -- root
1 365 365 365 4 365 S 0 0:00 /sbin/mingetty tty4
1 366 366 366 5 366 S 0 0:00 /sbin/mingetty tty5
1 367 367 367 6 367 S 0 0:00 /sbin/mingetty tty6
1 369 369 369 ? -1 S 0 0:00 update (bdflush)
362 370 370 362 1 370 S 400 0:00 -bash
363 602 602 363 2 965 S 0 0:00 -bash
1 922 922 922 3 961 S 0 0:00 /bin/login -- root
602 946 946 363 2 965 S 0 0:00 ./setsch
922 948 948 922 3 961 S 0 0:00 -bash
948 961 961 922 3 961 S 0 0:00 amp -t Smells_Like_Nirvana.
961 962 961 922 3 961 R 0 0:03 amp -t Smells_Like_Nirvana.
962 963 961 922 3 961 R 0 0:00 amp -t Smells_Like_Nirvana.
946 965 965 363 2 965 R 0 0:00 ps axj
Name: amp
State: S (sleeping)
Pid: 961
PPid: 948
Uid: 0 0 0 0
Gid: 0 0 0 0
VmSize: 972 kB
VmLck: 0 kB
VmRSS: 384 kB
VmData: 112 kB
VmStk: 16 kB
VmExe: 68 kB
VmLib: 708 kB
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCat: 0000000000000000
Name: amp
State: S (sleeping)
Pid: 962
PPid: 961
Uid: 0 0 0 0
Gid: 0 0 0 0
VmSize: 1104 kB
VmLck: 1036 kB
VmRSS: 992 kB
VmData: 180 kB
VmStk: 16 kB
VmExe: 68 kB
VmLib: 708 kB
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCat: 0000000000000000
Name: amp
State: S (sleeping)
Pid: 963
PPid: 962
Uid: 0 0 0 0
Gid: 0 0 0 0
VmSize: 1036 kB
VmLck: 1036 kB
VmRSS: 976 kB
VmData: 176 kB
VmStk: 16 kB
VmExe: 68 kB
VmLib: 708 kB
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCat: 0000000000000000
Name: amp
State: R (running)
Pid: 961
PPid: 948
Uid: 0 0 0 0
Gid: 0 0 0 0
VmSize: 972 kB
VmLck: 0 kB
VmRSS: 384 kB
VmData: 112 kB
VmStk: 16 kB
VmExe: 68 kB
VmLib: 708 kB
SigPnd: 0000000000000002
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCat: 0000000000000000
Name: amp
State: R (running)
Pid: 962
PPid: 961
Uid: 0 0 0 0
Gid: 0 0 0 0
SigPnd: 0000000000000002
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCat: 0000000000000000
Name: amp
State: R (running)
Pid: 963
PPid: 962
Uid: 0 0 0 0
Gid: 0 0 0 0
VmSize: 1036 kB
VmLck: 1036 kB
VmRSS: 976 kB
VmData: 176 kB
VmStk: 16 kB
VmExe: 68 kB
VmLib: 708 kB
SigPnd: 0000000000000002
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCat: 0000000000000000

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu