I attach a small program which does something simple: First it
programs a posix timer; the timer will send the process a SIGKILL signal
when it expires, so that the process should die. Then it loops without
end. It has also a handler for SIGUSR1 which will print the remaining
count for the timer if such signal is sent to the process.
Well, as a matter of fact, the process won’t die! If you kill it
BEFORE the timer has expired, it disappears, as expected. However, if
you wait for the timer to send the process SIGKILL, you find that a)
This does not kill the process b) You CANNOT kill the process, even with
SIGKILL. c) If you type ps -l -p , “ps” will loop forever
while it prints the stuff for the non-dead process over and over…
It happens under QNX 6.2, and QNX 6.1; it does not happen under
Solaris 2.6. The process dies, however, if the timer sends SIGTERM, and
its handler calls exit(0).
I attach a small program which does something simple: First it
programs a posix timer; the timer will send the process a SIGKILL signal
when it expires, so that the process should die. Then it loops without
end. It has also a handler for SIGUSR1 which will print the remaining
count for the timer if such signal is sent to the process.
Well, as a matter of fact, the process won’t die! If you kill it
BEFORE the timer has expired, it disappears, as expected. However, if
you wait for the timer to send the process SIGKILL, you find that a)
This does not kill the process b) You CANNOT kill the process, even with
SIGKILL. c) If you type ps -l -p , “ps” will loop forever
while it prints the stuff for the non-dead process over and over…
It happens under QNX 6.2, and QNX 6.1; it does not happen under
Solaris 2.6. The process dies, however, if the timer sends SIGTERM, and
its handler calls exit(0).
I attach a small program which does something simple: First it
programs a posix timer; the timer will send the process a SIGKILL signal
when it expires, so that the process should die. Then it loops without
end. It has also a handler for SIGUSR1 which will print the remaining
count for the timer if such signal is sent to the process.
Well, as a matter of fact, the process won’t die! If you kill it
BEFORE the timer has expired, it disappears, as expected. However, if
you wait for the timer to send the process SIGKILL, you find that a)
This does not kill the process b) You CANNOT kill the process, even with
SIGKILL. c) If you type ps -l -p , “ps” will loop forever
while it prints the stuff for the non-dead process over and over…
It happens under QNX 6.2, and QNX 6.1; it does not happen under
Solaris 2.6. The process dies, however, if the timer sends SIGTERM, and
its handler calls exit(0).
I attach a small program which does something simple: First it
programs a posix timer; the timer will send the process a SIGKILL signal
when it expires, so that the process should die. Then it loops without
end. It has also a handler for SIGUSR1 which will print the remaining
count for the timer if such signal is sent to the process.
Well, as a matter of fact, the process won’t die! If you kill it
BEFORE the timer has expired, it disappears, as expected. However, if
you wait for the timer to send the process SIGKILL, you find that a)
This does not kill the process b) You CANNOT kill the process, even with
SIGKILL. c) If you type ps -l -p , “ps” will loop forever
while it prints the stuff for the non-dead process over and over…
It happens under QNX 6.2, and QNX 6.1; it does not happen under
Solaris 2.6. The process dies, however, if the timer sends SIGTERM, and
its handler calls exit(0).
I have found that psin fails in lots of scenarios. Mainly when I want to
scroll down the viewable list of processes, and when I least expect it.
Pity really as it’s quite an informative utility.
I haven’t been inclined to mention it here before as I’m being quite
brutal with my machines in the area of interrupts and the odd timer or
three, and it could be argued that I am provoking it.
I’m learning to live without it (psin) but I find pidin and sin lacking
in some of the information I am after about what’s going on in the
system.
Geoff.
Robert Rutherford wrote:
We have reported a similar problem and so have a few others. Do you also
find that “psin” fails in this scenario?
I attach a small program which does something simple: First it
programs a posix timer; the timer will send the process a SIGKILL signal
when it expires, so that the process should die. Then it loops without
end. It has also a handler for SIGUSR1 which will print the remaining
count for the timer if such signal is sent to the process.
Well, as a matter of fact, the process won’t die! If you kill it
BEFORE the timer has expired, it disappears, as expected. However, if
you wait for the timer to send the process SIGKILL, you find that a)
This does not kill the process b) You CANNOT kill the process, even with
SIGKILL. c) If you type ps -l -p , “ps” will loop forever
while it prints the stuff for the non-dead process over and over…
It happens under QNX 6.2, and QNX 6.1; it does not happen under
Solaris 2.6. The process dies, however, if the timer sends SIGTERM, and
its handler calls exit(0).
Is this a system bug?
Best regards,
Joaquín Ferruz
\
–
Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA
We have reported a similar problem and so have a few others. Do you also
find that “psin” fails in this scenario?
So far the silence from QSSL has been deafening.
There was a PRed signal/termination issue against 6.2.0 that was, I think,
fixed for 6.2.1.
I haven’t further commented on this particular issue, because the source
was mime-encrypted. If it had been posted in plain, I probably would have
grabbed it and tested it.
Mime-encoding is ok for posting binary data (though I prefere uuencoded),
but C source is plain text data, and doesn’t need to be mime-encoded.
I have tested my program with “psin”. I have found no malfunction, even
when “temp” was hanged and it could not be killed with signals. “psin”
reported the state “NANOSLEEP”. As I said before, ps will go crazy, but only
if requested to display the full set of data ("-l" option).
Regards,
Joaquín Ferruz
David Gibbs wrote:
Robert Rutherford <> ruzz@nospamplease.ruzz.com> > wrote:
We have reported a similar problem and so have a few others. Do you also
find that “psin” fails in this scenario?
So far the silence from QSSL has been deafening.
There was a PRed signal/termination issue against 6.2.0 that was, I think,
fixed for 6.2.1.
I haven’t further commented on this particular issue, because the source
was mime-encrypted. If it had been posted in plain, I probably would have
grabbed it and tested it.
Mime-encoding is ok for posting binary data (though I prefere uuencoded),
but C source is plain text data, and doesn’t need to be mime-encoded.
I correct myself… “psin” works fine until requested to slay “temp”; in this
case, “psin” will hang, probably while waiting for “temp” to exit, something
that won’t happen. I cannot blame “psin” for that; the same would happen to me
If I were patient enough…
Regards,
Joaquin Ferruz
Joaquin Ferruz Melero wrote:
I have tested my program with “psin”. I have found no malfunction, even
when “temp” was hanged and it could not be killed with signals. “psin”
reported the state “NANOSLEEP”. As I said before, ps will go crazy, but only
if requested to display the full set of data ("-l" option).
Regards,
Joaquín Ferruz
David Gibbs wrote:
Robert Rutherford <> ruzz@nospamplease.ruzz.com> > wrote:
We have reported a similar problem and so have a few others. Do you also
find that “psin” fails in this scenario?
So far the silence from QSSL has been deafening.
There was a PRed signal/termination issue against 6.2.0 that was, I think,
fixed for 6.2.1.
I haven’t further commented on this particular issue, because the source
was mime-encrypted. If it had been posted in plain, I probably would have
grabbed it and tested it.
Mime-encoding is ok for posting binary data (though I prefere uuencoded),
but C source is plain text data, and doesn’t need to be mime-encoded.
