I have a psin process in memory which doesn’t do anything on any signal.
psin is not the only process concerned by this problem, it can happen on
other process, I don’t know why, but I cannot launch another psin and
the only solution I see is to reboot.
Why a process can stay in memory and ignore a SIGKILL?
How to flush such process?
Thanks,
Alain
“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3BDE52BB.8694650F@icbt.com…
I have a psin process in memory which doesn’t do anything on any signal.
psin is not the only process concerned by this problem, it can happen on
other process, I don’t know why, but I cannot launch another psin and
the only solution I see is to reboot.
That’s strange, I can slay off psin and/or do a kill-9
What version of QNX are you using? Does this happen even after a reboot?
-Adam
Operating System Tech Support a écrit :
“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3BDE52BB.8694650F@icbt.com> …
I have a psin process in memory which doesn’t do anything on any signal.
psin is not the only process concerned by this problem, it can happen on
other process, I don’t know why, but I cannot launch another psin and
the only solution I see is to reboot.That’s strange, I can slay off psin and/or do a kill-9
What version of QNX are you using? Does this happen even after a reboot?
-Adam
Sure, usually, that works!
I’m using 6.1a, that’s not the first time, I ever saw this problem in 6.0. It
happens rarely, certainly in a very particular circumstance which I don’t
know.
psin is still in memory if you have any idea about some test to do, I can do
it.
I’d like to know if there is a solution to flush it without rebooting.
Regards,
Alain.
Operating System Tech Support <os@qnx.com> wrote in article <9rmcm4$rcv$1@nntp.qnx.com>…
“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3BDE52BB.8694650F@icbt.com> …
I have a psin process in memory which doesn’t do anything on any signal.
psin is not the only process concerned by this problem, it can happen on
other process, I don’t know why, but I cannot launch another psin and
the only solution I see is to reboot.That’s strange, I can slay off psin and/or do a kill-9
What version of QNX are you using? Does this happen even after a reboot?
I think I saw this problem too. In my case it happened when devb-fdc was improperly started. I was
playing around floppy driver and the driver was started twice. The second copy of driver just
ignored any signals (to be honest I only tried to kill it 
).
Sometimes it can be reproduced after a reboot. Just start the second devb-fdc and then kill it. If
devb-fdc will killed, repeat the experiment. Or do these problems have differents roots?
Eduard.
-Adam
“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3BDFF30A.8804E166@icbt.com…
Sure, usually, that works!
Sorry, that’s not what I meant I was wondering if the problem was just
this one time or if it happens after a reboot. But you’ve answered that
already 
I’m using 6.1a, that’s not the first time, I ever saw this problem in 6.0.
It
happens rarely, certainly in a very particular circumstance which I don’t
know.psin is still in memory if you have any idea about some test to do, I can
do
it.
One thing to try is to start a shell at a higher priority then psin and try
killing it.
-Adam
ed1k <ed1k@yahoo.com> wrote in article 01c16211$14a97320$7b6fa8c0@ED1K…
My fault! I have made two mistakes. The first, to reproduce “unkilled” process just slay devb-fdc
and then start the driver improperly ‘devb-fdc cam lun=0x01’. The process will consists of two
threads: first with priority 10 and second with priority 21 in state INTR. The second, I am new in
unix and I was surprised the default signal for kill utility is SIGTERM. So I did not try to kill,
I tried to terminate process. The driver in that state ignores the signal SIGTERM regardless which
priority of kill sending the signal. SIGKILL makes effect of silver bullet 'kill -sigkill
’ works just fine.
Sorry, my problem related to my ignorance.
Eduard.
[…]
I think I saw this problem too. In my case it happened when devb-fdc was improperly started. I
was
playing around floppy driver and the driver was started twice. The second copy of driver just
ignored any signals (to be honest I only tried to kill it >
Sometimes it can be reproduced after a reboot. Just start the second devb-fdc and then kill it.
If
devb-fdc will killed, repeat the experiment. Or do these problems have differents roots?Eduard.
-Adam
\
Operating System Tech Support <os@qnx.com> wrote in article <9rrpdl$dp2$1@nntp.qnx.com>…
That is what a kill -9 is… 9 is a SIGKILL (see original post).
I know it now . I agree here I was wrong. I.E. I never saw this problem in my system. Just I
tried 'kill ’ in stupid assumption that kill sends sigkill. Sorry for my racket here.
Eduard.
-Adam
“ed1k” <ed1k@yahoo.com> wrote in message
news:01c162ae$81e9cfa0$7b6fa8c0@ED1K…
priority of kill sending the signal. SIGKILL makes effect of silver bullet
pid>’ works just fine.
Sorry, my problem related to my ignorance.
That is what a kill -9 is… 9 is a SIGKILL (see original post).
-Adam
“ed1k” <ed1k@yahoo.com> wrote in message
news:01c162ee$dc76db80$7b6fa8c0@ED1K…
I know it now >
in my system. >Just I tried 'kill ’ in stupid assumption that kill
sends sigkill. Sorry for my racket here.
No worries, I just wanted to make sure you knew that you can use numbers
instead of names.
-Adam
Operating System Tech Support <os@qnx.com> wrote in article <9rs9ou$nqm$1@nntp.qnx.com>…
No worries, I just wanted to make sure you knew that you can use numbers
instead of names.
As for me, I only found one strange thing: I can rid SIG prefix in signal name, but I can not do it
for SIGKILL. 'kill -term ’ works, but 'kill -kill ’ outputs tips for options.
I think this branch of thread is not related to original question. NRN
I just wanted to make sure you continue to look into Alain’s problem report.
Best regards,
Eduard.
Operating System Tech Support a écrit :
“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3BDFF30A.8804E166@icbt.com> …
Sure, usually, that works!Sorry, that’s not what I meant >
this one time or if it happens after a reboot. But you’ve answered that
already >I’m using 6.1a, that’s not the first time, I ever saw this problem in 6.0.
It
happens rarely, certainly in a very particular circumstance which I don’t
know.psin is still in memory if you have any idea about some test to do, I can
do
it.One thing to try is to start a shell at a higher priority then psin and try
killing it.-Adam
The problem in that case is that it’s not possible to start another psin. The
second session eats all free memory and exits.
About this problem of eating free memory, I got it using your example about
procmgr_event_notify and I related it in the thread ‘something not clean in
/proc’.
I wonder if there is no something in common between both problems.
Thanks,
Alain.