Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!apple!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!unido!opal!tmpmbx!utopia!sunrise!hotte From: hotte@sunrise.in-berlin.de (Horst Laumer) Newsgroups: comp.unix.internals Subject: Re: Signal Request Not Reaching Child Message-ID: Date: 30 Nov 90 00:09:12 GMT References: <1990Nov26.214748.5977@mdivax1.uucp> Organization: HL EDV-Beratung Lines: 32 In article <1990Nov26.214748.5977@mdivax1.uucp>: >A process (P) generates (and can kill) child processes. Children are >normally given a signal (kill -3) by P and kill themselves after cleaning >up and acknowledging P's request. >The problem is that (very rarely) a child process refuses to die. No >ack is sent to P. When in this state, even kill -9 will not kill the >child process. However, the child process handles terminal i/o and if >the terminal is shut off and on the child can be aborted. This makes >me think that the child is in a state where it cannot collect a software >signal, perhaps because it is in the middle of a screen write or some >terminal i/o. Could this be the case? What else could cause this? >Work around solutions would also be appreciated. Note: the terminal is >set up in BLOCK mode, if that makes any difference. >Thanks in advance for any suggestions/help. This seams to be a general bug. At least in SysV, when kill(pid,SIGKILL) doesn't work, this indicates that the recipient in in kernel mode and executing (better: hanging) the code of a device driver the kernel relies on (!). Since I do not know the process' job, assuming P knows the tty of this child this may be worked around by having P close the line and send the signal again. hl -- ============================================================================ Horst Laumer, Kantstrasse 107, D-1000 Berlin 12 ! Bang-Adress: Domain: hotte@sunrise.in-berlin.de ! Junk-Food for Autorouters Bang: ...unido!fub!geminix!sunrise!hotte ! -- me --