Can't interrupt flock with signal

QNX Newsgroups (Archives) qnx.rtos
1

Hello,

I can’t interrupt process with signal SIGALRM, SIGTERM, SIGKILL, … .
It is wait in function flock in state REPLY.

Start this example 2 times. First process will write “Locked successfuly”
Second process should after 2 second write
“Signal received: 14”
“Interrupted flock with error 4”, but do nothing. When I send other
signals to second process (SIGTERM, SIGKILL ), nothing happend.
I try it on QNX 6.1, 6.2.1 6.3

What I do wrong ?

Thanks Marian.

#include <signal.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>

void AlarmHandler( int sig_no )
{
fprintf( stdout, “Signal received: %d \n”, sig_no );
fflush( stdout );
return;
}

int main( void )
{
int fd;

signal( SIGALRM, AlarmHandler );

if( (fd = open( “/dev/ser1”, O_RDWR )) != -1 )
{
alarm( 2 );

if( flock( fd, LOCK_EX ) != 0 )
{
fprintf( stdout, “Interrupted flock with error %d\n”, errno );
fflush( stdout );
}
else
{
fprintf( stdout, “Locked successfully” );
fflush( stdout );
}
alarm( 0 );

for( ; ; )
{
delay( 1000 );
}

close( fd );
}

return 0;
}

2

Marian Oklapek <oklapek@pobox.sk> wrote:

Hello,

I can’t interrupt process with signal SIGALRM, SIGTERM, SIGKILL, … .
It is wait in function flock in state REPLY.

Start this example 2 times. First process will write “Locked successfuly”
Second process should after 2 second write
“Signal received: 14”
“Interrupted flock with error 4”, but do nothing. When I send other
signals to second process (SIGTERM, SIGKILL ), nothing happend.
I try it on QNX 6.1, 6.2.1 6.3

What I do wrong ?

The failure to unblock your second process looks like a bug in the
serial driver to me. I issued a PR against it, PR 22656.

But, I should note that flock() is meant to apply to a “file”, and
/dev/ser1 isn’t really a “file”, so I’m not sure flock() is really
supposed to be used on serial devices.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

3

David Gibbs wrote:

But, I should note that flock() is meant to apply to a “file”, and
/dev/ser1 isn’t really a “file”, so I’m not sure flock() is really
supposed to be used on serial devices.

I’d expect flock() to work (it applies an “advisory lock” to a file,
which can, apparently, be ignored) because it only works on an entire
file. I wouldn’t expect lockf() to work because it locks a specific
section of a file…

It's probably common practice to flock() /dev/ser* in Unix code, since I wouldn't expect the driver to do anything sane like that.

:wink:

–
Chris Herborth (cherborth@qnx.com)
Never send a monster to do the work of an evil scientist.

4
It's apparently common belief @ QNX that behavior of 'uncatchable' signals like SIGKILL should be left to the developers of drivers. If they bothered to handle the unblock pulse, signals will work as people from [insane] Unix background expect. Otherwise they won't.

“Chris Herborth” <cherborth@qnx.com> wrote in message
news:cntad5$b9i$1@inn.qnx.com…

David Gibbs wrote:
But, I should note that flock() is meant to apply to a “file”, and
/dev/ser1 isn’t really a “file”, so I’m not sure flock() is really
supposed to be used on serial devices.

I’d expect flock() to work (it applies an “advisory lock” to a file,
which can, apparently, be ignored) because it only works on an entire
file. I wouldn’t expect lockf() to work because it locks a specific
section of a file…

bias
It’s probably common practice to flock() /dev/ser* in Unix code, since I
wouldn’t expect the driver to do anything sane like that.
/bias

:wink:

–
Chris Herborth (> cherborth@qnx.com> )
Never send a monster to do the work of an evil scientist.

5

Igor Kovalenko <kovalenko@comcast.net> wrote:

bias
It’s apparently common belief @ QNX that behavior of ‘uncatchable’ signals
like SIGKILL should be left to the developers of drivers. If they bothered
to handle the unblock pulse, signals will work as people from [insane] Unix
background expect. Otherwise they won’t.
/bias

sigh

I’ve got a Linux Redhat 9 box on my desk. I had a process that I couldn’t
SIGKILL on it, too, cause it had started a kernel operation that hadn’t
completed. In A traditional Unix, a driver in the kernel can generally
hold off signals for a process called into the kernel, all signals.

Under QNX, what would normally be part of the kernel has been moved
out to process space – but is still given many of the traditional
capabilities of the Unix kernel.

Under Linux, you write a bad loadable kernel driver, you get this
behaviour.

Under QNX you write a bad process-based driver, you get this behaviour.

-David

“Chris Herborth” <> cherborth@qnx.com> > wrote in message
news:cntad5$b9i$> 1@inn.qnx.com> …
David Gibbs wrote:
But, I should note that flock() is meant to apply to a “file”, and
/dev/ser1 isn’t really a “file”, so I’m not sure flock() is really
supposed to be used on serial devices.

I’d expect flock() to work (it applies an “advisory lock” to a file,
which can, apparently, be ignored) because it only works on an entire
file. I wouldn’t expect lockf() to work because it locks a specific
section of a file…

bias
It’s probably common practice to flock() /dev/ser* in Unix code, since I
wouldn’t expect the driver to do anything sane like that.
/bias

:wink:

–
Chris Herborth (> cherborth@qnx.com> )
Never send a monster to do the work of an evil scientist.

–
David Gibbs
QNX Training Services
dagibbs@qnx.com

6

yawn

  1. Linux is not Unix. And not a good role model, at any rate.

  2. Instead of hearing ‘him too’ I’d appreciate a substantiated argument why
    QNX can’t make sure that SIGKILL/etc always do kill a process. I would think
    that holding off signals until server has handled unblock pulses implies the
    will of a developer to handle them. Which he/she should have explicitly
    indicated by setting some channel flag. And if such a flag is not set, it
    should not be a problem to just kill the darn thing - after all the
    developer DOES NOT CARE. That would have been IMHO a sensible design.

  3. Since your design is different already, I still can’t see why a flag ‘do
    not hold off signals’ can not be provided for channels… Along with a flag
    to make all connections side-channel by default (that’s another example of
    QNX making default behavior of system based on non-default behavior of
    programmers).

– igor

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:cnvi80$3qq$1@inn.qnx.com…

Igor Kovalenko <> kovalenko@comcast.net> > wrote:
bias
It’s apparently common belief @ QNX that behavior of ‘uncatchable’
signals
like SIGKILL should be left to the developers of drivers. If they
bothered
to handle the unblock pulse, signals will work as people from [insane]
Unix
background expect. Otherwise they won’t.
/bias

sigh

I’ve got a Linux Redhat 9 box on my desk. I had a process that I couldn’t
SIGKILL on it, too, cause it had started a kernel operation that hadn’t
completed. In A traditional Unix, a driver in the kernel can generally
hold off signals for a process called into the kernel, all signals.

Under QNX, what would normally be part of the kernel has been moved
out to process space – but is still given many of the traditional
capabilities of the Unix kernel.

Under Linux, you write a bad loadable kernel driver, you get this
behaviour.

Under QNX you write a bad process-based driver, you get this behaviour.

-David

“Chris Herborth” <> cherborth@qnx.com> > wrote in message
news:cntad5$b9i$> 1@inn.qnx.com> …
David Gibbs wrote:
But, I should note that flock() is meant to apply to a “file”, and
/dev/ser1 isn’t really a “file”, so I’m not sure flock() is really
supposed to be used on serial devices.

I’d expect flock() to work (it applies an “advisory lock” to a file,
which can, apparently, be ignored) because it only works on an entire
file. I wouldn’t expect lockf() to work because it locks a specific
section of a file…

bias
It’s probably common practice to flock() /dev/ser* in Unix code, since
I
wouldn’t expect the driver to do anything sane like that.
/bias

:wink:

–
Chris Herborth (> cherborth@qnx.com> )
Never send a monster to do the work of an evil scientist.


\

David Gibbs
QNX Training Services
dagibbs@qnx.com

7

This flag exists already. See the docs ChannelCreate and
the _NTO_CHF_UNBLOCK flag. It works exactly as you describe.

-seanb

Igor Kovalenko <kovalenko@comcast.net> wrote:

yawn

  1. Linux is not Unix. And not a good role model, at any rate.

  2. Instead of hearing ‘him too’ I’d appreciate a substantiated argument why
    QNX can’t make sure that SIGKILL/etc always do kill a process. I would think
    that holding off signals until server has handled unblock pulses implies the
    will of a developer to handle them. Which he/she should have explicitly
    indicated by setting some channel flag. And if such a flag is not set, it
    should not be a problem to just kill the darn thing - after all the
    developer DOES NOT CARE. That would have been IMHO a sensible design.

  3. Since your design is different already, I still can’t see why a flag ‘do
    not hold off signals’ can not be provided for channels… Along with a flag
    to make all connections side-channel by default (that’s another example of
    QNX making default behavior of system based on non-default behavior of
    programmers).

– igor

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:cnvi80$3qq$> 1@inn.qnx.com> …
Igor Kovalenko <> kovalenko@comcast.net> > wrote:
bias
It’s apparently common belief @ QNX that behavior of ‘uncatchable’
signals
like SIGKILL should be left to the developers of drivers. If they
bothered
to handle the unblock pulse, signals will work as people from [insane]
Unix
background expect. Otherwise they won’t.
/bias

sigh

I’ve got a Linux Redhat 9 box on my desk. I had a process that I couldn’t
SIGKILL on it, too, cause it had started a kernel operation that hadn’t
completed. In A traditional Unix, a driver in the kernel can generally
hold off signals for a process called into the kernel, all signals.

Under QNX, what would normally be part of the kernel has been moved
out to process space – but is still given many of the traditional
capabilities of the Unix kernel.

Under Linux, you write a bad loadable kernel driver, you get this
behaviour.

Under QNX you write a bad process-based driver, you get this behaviour.

-David

“Chris Herborth” <> cherborth@qnx.com> > wrote in message
news:cntad5$b9i$> 1@inn.qnx.com> …
David Gibbs wrote:
But, I should note that flock() is meant to apply to a “file”, and
/dev/ser1 isn’t really a “file”, so I’m not sure flock() is really
supposed to be used on serial devices.

I’d expect flock() to work (it applies an “advisory lock” to a file,
which can, apparently, be ignored) because it only works on an entire
file. I wouldn’t expect lockf() to work because it locks a specific
section of a file…

bias
It’s probably common practice to flock() /dev/ser* in Unix code, since
I
wouldn’t expect the driver to do anything sane like that.
/bias

:wink:

–
Chris Herborth (> cherborth@qnx.com> )
Never send a monster to do the work of an evil scientist.


\

David Gibbs
QNX Training Services
dagibbs@qnx.com

8

Yeah. But ‘raw’ channels is not what QNX resource managers usually do,
right? When channels are created by resmgr/dispatch functions, I believe
this flag is always set, whether or not somebody is going to handle those
pulses.

“Sean Boudreau” <seanb@qnx.com> wrote in message
news:cnvst0$bpt$1@inn.qnx.com…

This flag exists already. See the docs ChannelCreate and
the _NTO_CHF_UNBLOCK flag. It works exactly as you describe.

-seanb

Igor Kovalenko <> kovalenko@comcast.net> > wrote:
yawn

  1. Linux is not Unix. And not a good role model, at any rate.

  2. Instead of hearing ‘him too’ I’d appreciate a substantiated argument
    why
    QNX can’t make sure that SIGKILL/etc always do kill a process. I would
    think
    that holding off signals until server has handled unblock pulses implies
    the
    will of a developer to handle them. Which he/she should have explicitly
    indicated by setting some channel flag. And if such a flag is not set,
    it
    should not be a problem to just kill the darn thing - after all the
    developer DOES NOT CARE. That would have been IMHO a sensible design.

  3. Since your design is different already, I still can’t see why a flag
    ‘do
    not hold off signals’ can not be provided for channels… Along with a
    flag
    to make all connections side-channel by default (that’s another example
    of
    QNX making default behavior of system based on non-default behavior of
    programmers).

– igor

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:cnvi80$3qq$> 1@inn.qnx.com> …
Igor Kovalenko <> kovalenko@comcast.net> > wrote:
bias
It’s apparently common belief @ QNX that behavior of ‘uncatchable’
signals
like SIGKILL should be left to the developers of drivers. If they
bothered
to handle the unblock pulse, signals will work as people from
[insane]
Unix
background expect. Otherwise they won’t.
/bias

sigh

I’ve got a Linux Redhat 9 box on my desk. I had a process that I
couldn’t
SIGKILL on it, too, cause it had started a kernel operation that hadn’t
completed. In A traditional Unix, a driver in the kernel can generally
hold off signals for a process called into the kernel, all signals.

Under QNX, what would normally be part of the kernel has been moved
out to process space – but is still given many of the traditional
capabilities of the Unix kernel.

Under Linux, you write a bad loadable kernel driver, you get this
behaviour.

Under QNX you write a bad process-based driver, you get this behaviour.

-David

“Chris Herborth” <> cherborth@qnx.com> > wrote in message
news:cntad5$b9i$> 1@inn.qnx.com> …
David Gibbs wrote:
But, I should note that flock() is meant to apply to a “file”, and
/dev/ser1 isn’t really a “file”, so I’m not sure flock() is really
supposed to be used on serial devices.

I’d expect flock() to work (it applies an “advisory lock” to a file,
which can, apparently, be ignored) because it only works on an
entire
file. I wouldn’t expect lockf() to work because it locks a specific
section of a file…

bias
It’s probably common practice to flock() /dev/ser* in Unix code,
since
I
wouldn’t expect the driver to do anything sane like that.
/bias

:wink:

–
Chris Herborth (> cherborth@qnx.com> )
Never send a monster to do the work of an evil scientist.


\

David Gibbs
QNX Training Services
dagibbs@qnx.com

9

Thanks,

Now I know, why I can not interrupt my process - _NTO_CHF_UNBLOCK is
set on the server side
and server has wrong (no) reaction to pulse _PULSE_CODE_UNBLOCK ( it
is in documentation ).

Please check function tcdrain too - happen some similar.

Marian.

Igor Kovalenko wrote:

Yeah. But ‘raw’ channels is not what QNX resource managers usually do,
right? When channels are created by resmgr/dispatch functions, I believe
this flag is always set, whether or not somebody is going to handle those
pulses.

“Sean Boudreau” <> seanb@qnx.com> > wrote in message
news:cnvst0$bpt$> 1@inn.qnx.com> …

This flag exists already. See the docs ChannelCreate and
the _NTO_CHF_UNBLOCK flag. It works exactly as you describe.

-seanb

Igor Kovalenko <> kovalenko@comcast.net> > wrote:

yawn

  1. Linux is not Unix. And not a good role model, at any rate.

  2. Instead of hearing ‘him too’ I’d appreciate a substantiated argument

why

QNX can’t make sure that SIGKILL/etc always do kill a process. I would

think

that holding off signals until server has handled unblock pulses implies

the

will of a developer to handle them. Which he/she should have explicitly
indicated by setting some channel flag. And if such a flag is not set,

it

should not be a problem to just kill the darn thing - after all the
developer DOES NOT CARE. That would have been IMHO a sensible design.

  1. Since your design is different already, I still can’t see why a flag

'do

not hold off signals’ can not be provided for channels… Along with a

flag

to make all connections side-channel by default (that’s another example

of

QNX making default behavior of system based on non-default behavior of
programmers).

– igor

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:cnvi80$3qq$> 1@inn.qnx.com> …

Igor Kovalenko <> kovalenko@comcast.net> > wrote:

bias
It’s apparently common belief @ QNX that behavior of ‘uncatchable’

signals

like SIGKILL should be left to the developers of drivers. If they

bothered

to handle the unblock pulse, signals will work as people from

[insane]

Unix

background expect. Otherwise they won’t.
/bias

sigh

I’ve got a Linux Redhat 9 box on my desk. I had a process that I

couldn’t

SIGKILL on it, too, cause it had started a kernel operation that hadn’t
completed. In A traditional Unix, a driver in the kernel can generally
hold off signals for a process called into the kernel, all signals.

Under QNX, what would normally be part of the kernel has been moved
out to process space – but is still given many of the traditional
capabilities of the Unix kernel.

Under Linux, you write a bad loadable kernel driver, you get this
behaviour.

Under QNX you write a bad process-based driver, you get this behaviour.

-David


“Chris Herborth” <> cherborth@qnx.com> > wrote in message
news:cntad5$b9i$> 1@inn.qnx.com> …

David Gibbs wrote:

But, I should note that flock() is meant to apply to a “file”, and
/dev/ser1 isn’t really a “file”, so I’m not sure flock() is really
supposed to be used on serial devices.

I’d expect flock() to work (it applies an “advisory lock” to a file,
which can, apparently, be ignored) because it only works on an

entire

file. I wouldn’t expect lockf() to work because it locks a specific
section of a file…

bias
It’s probably common practice to flock() /dev/ser* in Unix code,

since

I

wouldn’t expect the driver to do anything sane like that.
/bias

:wink:

–
Chris Herborth (> cherborth@qnx.com> )
Never send a monster to do the work of an evil scientist.


\

David Gibbs
QNX Training Services
dagibbs@qnx.com
\

10

Marian Oklapek <oklapek@pobox.sk> wrote:

Thanks,

Now I know, why I can not interrupt my process - _NTO_CHF_UNBLOCK is
set on the server side
and server has wrong (no) reaction to pulse _PULSE_CODE_UNBLOCK ( it
is in documentation ).

Please check function tcdrain too - happen some similar.

Ok, I’ll see if I can get a rerproduceable case with tcdrain() too.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com