Commands stop responding to CTRL-C

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

This message is directed to normal QNX users. Please, if you are a QSSL
employee, do not respond unless you’ve experienced this problem.

I am attempting to resolve this problem thorough QNX support, but the
person I’m working with has not experienced the problem, and I’m having
trouble explaining what the issue is.

Here’s what I see: I am working along in a PTerm window, typing commands
in at the command line. I get to a point where I need to cancel out of a
command, such as “ps -ef | more” and hit CTRL-C. Nothing happens. I hit
CTRL-C again. Still, nothing happens. I hit CTRL-Z, CTRL-X, and nothing
happens. I have to open another PTerm window and slay the command.

Back in the original window, I’m back at the command line. From here, I
can hit CTRL-C, and the shell responds normally by presenting another
command line.

Have you ever had CTRL-C stop responding as it should within a PTerm
window? Is there any one thing that seems to trigger it? So far, I can’t
find anything that I’m doing to trigger the problem.

2

does stty show -isig?

-seanb

/home/seanb >stty
Name: /dev/ttypb
Type: pseudo
Opens: 2
+edit -isig +echok
+osflow

/home/seanb > stty +isig



Mathew Kirsch <mkirsch@ocdus.jnj.com> wrote:

This message is directed to normal QNX users. Please, if you are a QSSL
employee, do not respond unless you’ve experienced this problem.

I am attempting to resolve this problem thorough QNX support, but the
person I’m working with has not experienced the problem, and I’m having
trouble explaining what the issue is.

Here’s what I see: I am working along in a PTerm window, typing commands
in at the command line. I get to a point where I need to cancel out of a
command, such as “ps -ef | more” and hit CTRL-C. Nothing happens. I hit
CTRL-C again. Still, nothing happens. I hit CTRL-Z, CTRL-X, and nothing
happens. I have to open another PTerm window and slay the command.

Back in the original window, I’m back at the command line. From here, I
can hit CTRL-C, and the shell responds normally by presenting another
command line.

Have you ever had CTRL-C stop responding as it should within a PTerm
window? Is there any one thing that seems to trigger it? So far, I can’t
find anything that I’m doing to trigger the problem.

3

Mathew Kirsch <mkirsch@ocdus.jnj.com> wrote in message
news:b9olbe$el9$1@inn.qnx.com…

This message is directed to normal QNX users. Please, if you are a QSSL
employee, do not respond unless you’ve experienced this problem.

I am attempting to resolve this problem thorough QNX support, but the
person I’m working with has not experienced the problem, and I’m having
trouble explaining what the issue is.

Here’s what I see: I am working along in a PTerm window, typing commands
in at the command line. I get to a point where I need to cancel out of a
command, such as “ps -ef | more” and hit CTRL-C. Nothing happens. I hit
CTRL-C again. Still, nothing happens. I hit CTRL-Z, CTRL-X, and nothing
happens. I have to open another PTerm window and slay the command.

Umm, when piping to more (or less), you should hit ‘q’ to quit ; they won’t
let you escape via cntrl-c.

Back in the original window, I’m back at the command line. From here, I
can hit CTRL-C, and the shell responds normally by presenting another
command line.

Sure each process is allowed to intecept and handle signals as they see fit
(except for SIGKILL etc)

Have you ever had CTRL-C stop responding as it should within a PTerm
window? Is there any one thing that seems to trigger it? So far, I can’t
find anything that I’m doing to trigger the problem.

If the process isn’t handling signals, then look at using stty to querry the
‘break’ ability of the terminal as Sean suggested. If this is just
involving the more/less util, you can’t ctrl-c out; hit ‘q’ to quit.

-Adam

4

Adam Mallory wrote:

Umm, when piping to more (or less), you should hit ‘q’ to quit ; they won’t
let you escape via cntrl-c.

If the process isn’t handling signals, then look at using stty to querry the
‘break’ ability of the terminal as Sean suggested. If this is just
involving the more/less util, you can’t ctrl-c out; hit ‘q’ to quit.

Okay, more was a bad example. The problem is actually not specific to
any one utility.

5

Sean Boudreau wrote:

does stty show -isig?

Not normally.

You guys certainly do NOT follow directions very well…

6

Mathew Kirsch <mkirsch@ocdus.jnj.com> wrote in message
news:b9qttu$4cn$1@inn.qnx.com…

Adam Mallory wrote:
Umm, when piping to more (or less), you should hit ‘q’ to quit ; they
won’t
let you escape via cntrl-c.

If the process isn’t handling signals, then look at using stty to querry
the
‘break’ ability of the terminal as Sean suggested. If this is just
involving the more/less util, you can’t ctrl-c out; hit ‘q’ to quit.

Okay, more was a bad example. The problem is actually not specific to
any one utility.

It’s hard to help someone who gives bad examples/incomplete information.

Regardless, control-c is not guaranteed to always be able to terminate a
process. If you want to terminate a process, do so with SIGKILL via the
kill/slay command.

-Adam

7

Mathew Kirsch <mkirsch@ocdus.jnj.com> wrote in message
news:b9qu5q$4cn$2@inn.qnx.com…

Sean Boudreau wrote:
does stty show -isig?

Not normally.

You guys certainly do NOT follow directions very well…

Please, help us help you. Provide an example which shows the behaviour,
and/or much more detail on the circumstances of the occurrence if you can’t
recreate it. If it’s difficult to recreate the problem, imagine how hard it
is to diagnose the problem with very little information (short of “stuff
doesn’t work occasionally” which was provided). Further, non-constructive
commentary is exactly that; please refrain from it if you wish people to
assist you.

-Adam

8

“Adam Mallory” <amallory@qnx.com> wrote in message
news:b9r04v$2de$1@nntp.qnx.com…

Mathew Kirsch <> mkirsch@ocdus.jnj.com> > wrote in message
news:b9qttu$4cn$> 1@inn.qnx.com> …
Adam Mallory wrote:
Umm, when piping to more (or less), you should hit ‘q’ to quit ; they
won’t
let you escape via cntrl-c.

If the process isn’t handling signals, then look at using stty to
querry
the
‘break’ ability of the terminal as Sean suggested. If this is just
involving the more/less util, you can’t ctrl-c out; hit ‘q’ to quit.

Okay, more was a bad example. The problem is actually not specific to
any one utility.

It’s hard to help someone who gives bad examples/incomplete information.

Regardless, control-c is not guaranteed to always be able to terminate a
process. If you want to terminate a process, do so with SIGKILL via the
kill/slay command.

Unfortunately, SIGKILL is not guaranteed to kill a process either, under
QNX. The most common (and annoying) case is when a client is stuck
REPLY-blocked on a server that is not ever going to reply. No matter what
you do, you just can’t kill such a client until you kill the server. If the
server happens to be something like devb-eide, you’re SOL.

I am aware of the rationale behind this behavior. However I disagree with
treating all signals like that. Unmaskable signals like SIGKILL should not
be affected. After all, when you use SIGKILL you probably don’t care about
what happens with your unreplied requests on the server side. Most likely,
nothing good is gonna happen to them anyway.

– igor

9

Igor Kovalenko <kovalenko@attbi.com> wrote in message
news:b9r4b7$ba7$1@inn.qnx.com…

Unfortunately, SIGKILL is not guaranteed to kill a process either, under
QNX. The most common (and annoying) case is when a client is stuck
REPLY-blocked on a server that is not ever going to reply. No matter what
you do, you just can’t kill such a client until you kill the server. If
the
server happens to be something like devb-eide, you’re SOL.

I was going to mention this, but I figured it wasn’t relevant since that’s
not what he sees (given that he could slay the process from another terminal
window).

I am aware of the rationale behind this behavior. However I disagree with
treating all signals like that. Unmaskable signals like SIGKILL should not
be affected. After all, when you use SIGKILL you probably don’t care about
what happens with your unreplied requests on the server side. Most likely,
nothing good is gonna happen to them anyway.

Yes, it’s hard to make all sides happy in less then ideal situations. That
said, when you SIGKILL the client, it’s not about what you (as the client)
care about WRT the server, it’s what the server cares about. Not to mention
the ever on going fight against breaking already existing behaviour some
people may have banked on (regardless of if it was correct to assume or
not - as we’ve all seen before) gives us pause before we change anything
like this.

-Adam

10

“Adam Mallory” <amallory@qnx.com> wrote in message
news:b9r6f4$cdr$1@nntp.qnx.com…

Igor Kovalenko <> kovalenko@attbi.com> > wrote in message
news:b9r4b7$ba7$> 1@inn.qnx.com> …

Unfortunately, SIGKILL is not guaranteed to kill a process either, under
QNX. The most common (and annoying) case is when a client is stuck
REPLY-blocked on a server that is not ever going to reply. No matter
what
you do, you just can’t kill such a client until you kill the server. If
the
server happens to be something like devb-eide, you’re SOL.

I was going to mention this, but I figured it wasn’t relevant since that’s
not what he sees (given that he could slay the process from another
terminal
window).

I am aware of the rationale behind this behavior. However I disagree
with
treating all signals like that. Unmaskable signals like SIGKILL should
not
be affected. After all, when you use SIGKILL you probably don’t care
about
what happens with your unreplied requests on the server side. Most
likely,
nothing good is gonna happen to them anyway.

Yes, it’s hard to make all sides happy in less then ideal situations.
That
said, when you SIGKILL the client, it’s not about what you (as the client)
care about WRT the server, it’s what the server cares about. Not to
mention
the ever on going fight against breaking already existing behaviour some
people may have banked on (regardless of if it was correct to assume or
not - as we’ve all seen before) gives us pause before we change anything
like this.

Hypothetically speaking, the latter would be a valid argument. In practice,
you usually use SIGKILL as an “extreme” measure (after SIGINT and SIGTERM
did not work). Naturally, that means I want the client dead and am willing
to disregard whatever the hell the server ‘thinks’. Do I have that right or
not? It is my system after all, I should be the ultimate authority. I
totally disagree with the notion that ‘it is not about what I (as the
client) think’.

So yes, make your pause, but don’t fall into another extreme (don’t change
anything even if it is bad). I’d bet nobody is banking on holding SIGKILL -
it is an unamaskable signal anyway so nobody makes any assumptions about
it. I am not asking to change behavior for all signals, only unmaskable
ones. If a server could not reply for long enough time to make me SIGKILL
the client, it is probably not going to reply ever. Then it could just as
well discard the request. It should of course still receive the notification
about client willing to disconnect to do that.

As an alternative route, I could ask you (as QNX) to fix all your shipped
servers so that they honor clients’ wish to disconnect. But I know that is
too much to ask :wink:

– igor

11

Thanks for your help.

12

Thanks for your help.

13

Igor Kovalenko <kovalenko@attbi.com> wrote in message
news:b9r7jg$emf$1@inn.qnx.com…

Hypothetically speaking, the latter would be a valid argument. In
practice,
you usually use SIGKILL as an “extreme” measure (after SIGINT and SIGTERM
did not work). Naturally, that means I want the client dead and am willing
to disregard whatever the hell the server ‘thinks’. Do I have that right
or
not? It is my system after all, I should be the ultimate authority. I
totally disagree with the notion that ‘it is not about what I (as the
client) think’.

I think you misunderstood what I meant. I agree that you should be able to
kill of all processes, and you should care less about what the server
thinks. The only problem that I see is making a inherently syncronus
exchange become asyncronous.

That said, not everyone plays nice and does a SIGINT/SIGTERM/SIGKILL
pattern, some just SIGKILL right away.

So yes, make your pause, but don’t fall into another extreme (don’t change
anything even if it is bad). I’d bet nobody is banking on holding
SIGKILL -
it is an unamaskable signal anyway so nobody makes any assumptions about
it.

I think that’s a nieve view - many times I am still surprised as to some of
the behaviour people bank on explicitly (and implicitly without
realization). Breaking that behaviour (good or bad) gives those people
heartburn, and some flat out expect you to support the incorrect behaviour
all the way through, and they could care less if the change is actually an
improvement.

While in the limited scope of SIGKILL, I’m sure no one is banking on holding
off SIGKILL on the client, but I’m sure people are not prepared for the
aftermath of changing that behaviour such that the server is not in sync
with the client.

I am not asking to change behavior for all signals, only unmaskable
ones. If a server could not reply for long enough time to make me SIGKILL
the client, it is probably not going to reply ever. Then it could just as
well discard the request. It should of course still receive the
notification
about client willing to disconnect to do that.

I agree.

As an alternative route, I could ask you (as QNX) to fix all your shipped
servers so that they honor clients’ wish to disconnect. But I know that is
too much to ask > :wink:

It’s not too much to ask at all. Through the official channels everything
is possible.

-Adam

14

“Adam Mallory” <amallory@qnx.com> wrote in message
news:b9rc0f$j0f$1@nntp.qnx.com…
…

Igor Kovalenko <> kovalenko@attbi.com> > wrote in message
I am not asking to change behavior for all signals, only unmaskable
ones. If a server could not reply for long enough time to make me
SIGKILL
the client, it is probably not going to reply ever. Then it could just
as
well discard the request. It should of course still receive the
notification
about client willing to disconnect to do that.

I agree.

As an alternative route, I could ask you (as QNX) to fix all your
shipped
servers so that they honor clients’ wish to disconnect. But I know that
is
too much to ask > :wink:

It’s not too much to ask at all. Through the official channels everything
is possible.

Perhaps. But there is no guarantee that tomorrow there won’t be a new one
that is broken again, and then we have to ask through official channel
again. There has to be a way to kill any arbitrary process regardless of
anything, so it can be used in such cases. The current situation where you
actually have to kill the server is not any better.

As of breaking existing behavior, you could add a ‘backward compatibility’
option to procnto so it can behave either way wrt SIGKILL.

– igor

15

Igor Kovalenko <kovalenko@attbi.com> wrote in message
news:b9uq5k$k5n$1@inn.qnx.com…

Perhaps. But there is no guarantee that tomorrow there won’t be a new one
that is broken again, and then we have to ask through official channel
again. There has to be a way to kill any arbitrary process regardless of
anything, so it can be used in such cases. The current situation where you
actually have to kill the server is not any better.

Like I mentioned previously, I agree that processes should never become
onipitent.

As of breaking existing behavior, you could add a ‘backward compatibility’
option to procnto so it can behave either way wrt SIGKILL.

If we made options for each behaviour we changed to keep ‘backward
compatibility’ we would have so many options it would be confusing (not to
mention the possibility of 2+ code paths, which is a testing nightmare). I
suppose one could make an interim release with the double code path, and
take the old behaviour out in a future/next release; still pretty nasty for
testing.

Thanks for the input :slight_smile:

-Adam