Question about Linux signal handling

Question about Linux signal handling

[Tom Sanders]

If I catch a signal (SIGUSR2) using "sigaction" call
then is the signal handler replaced with default
handling, if I don't install the signal handler again?

I remember that in UNIX "signal" system call default
signal bahavior was to replace the signal handler with
default after everytime signal was received?

My observation is that even if I get same signal
twice, I get the same print (which I have in my signal
handler) again, illustrating that signal handler was
not replaced with default !!! Is that the correct
behavior of "sigaction"?

Thanks,
Tom

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: Question about Linux signal handling

[Jesse Pollard]

On Saturday 22 February 2003 22:45, Tom Sanders wrote:
> If I catch a signal (SIGUSR2) using "sigaction" call
> then is the signal handler replaced with default
> handling, if I don't install the signal handler again?
>
> I remember that in UNIX "signal" system call default
> signal bahavior was to replace the signal handler with
> default after everytime signal was received?
>
> My observation is that even if I get same signal
> twice, I get the same print (which I have in my signal
> handler) again, illustrating that signal handler was
> not replaced with default !!! Is that the correct
> behavior of "sigaction"?

Depends on the value of sa_flags parameter:

>From the manpage SIGACTION(2):

       sa_flags  specifies  a  set  of  flags  which  modify  the
       behaviour  of the signal handling process. It is formed by
       the bitwise OR of zero or more of the following:
 
              SA_NOCLDSTOP
                     If signum is SIGCHLD, do not receive notifi-
                     cation when child processes stop (i.e., when
                     child  processes  receive  one  of  SIGSTOP,
                     SIGTSTP, SIGTTIN or SIGTTOU).
 
              SA_ONESHOT or SA_RESETHAND
                     Restore  the  signal  action  to the default
                     state  once  the  signal  handler  has  been
                     called.   (This  is  the default behavior of
                     the signal(2) system call.)
 
              SA_RESTART
                     Provide behaviour compatible with BSD signal
                     semantics  by  making  certain  system calls
                     restartable across signals.
 
              SA_NOMASK or SA_NODEFER
                     Do  not  prevent  the  signal   from   being
                     received from within its own signal handler.
 
              SA_SIGINFO
                     The signal handler takes  3  arguments,  not
                     one.   In  this case, sa_sigaction should be
                     set instead of sa_handler.   (The  sa_sigac-
                     tion field was added in Linux 2.1.86.)

You are describing SA_ONESHOT as what you think you should
get..

I believe you are getting the correct result. With the ONESHOT option
you can/will loose signals, since the handler would be set back to the
default, and any subsequent signal lost. This loss of signals is one of the
original complaints about UNIX signal handling.

Now my manpage continues with the warning:

       The  POSIX  spec  only defines SA_NOCLDSTOP.  Use of other
       sa_flags is non-portable.

and:

CONFORMING TO
       POSIX,  SVr4.  SVr4 does not document the EINTR condition.

Re: Question about Linux signal handling

[Albert Cahalan]

Tom Sanders writes:

> If I catch a signal (SIGUSR2) using "sigaction" call
> then is the signal handler replaced with default
> handling, if I don't install the signal handler again?

That depends on how you set sa_flags. Read the
sigaction man page.

> I remember that in UNIX "signal" system call default
> signal bahavior was to replace the signal handler with
> default after everytime signal was received?

Yes. This is the behavior of all SysV UNIX systems
and Linux kernels. Unfortunately, BSD got it wrong.
Worse, the glibc developers saw fit to ignore both
UNIX history and Linus. They implemented BSD behavior
by making signal() use the sigaction system call
instead of the signal system call. This of course
makes it harder to port apps from SysV UNIX systems
to Linux. Use sigaction() in all new code.

Re: Question about Linux signal handling

[Albert Cahalan]

On Sun, 2003-02-23 at 18:43, Alan Cox wrote:
> On Sun, 2003-02-23 at 22:29, Albert Cahalan wrote:

>> Yes. This is the behavior of all SysV UNIX systems
>> and Linux kernels. Unfortunately, BSD got it wrong.
>
> Firstly BSD didn't get it wrong, things merely diverged
> historically after V7 unix.

BSD is wrong for not choosing a different name
for the new system call and leaving the old one.
There could have been a signal2() with the new
behavior. X/Open even did this, with bsd_signal()
as the name. Breaking compatibility is bad.

>> Worse, the glibc developers saw fit to ignore both
>> UNIX history and Linus. They implemented BSD behavior
>> by making signal() use the sigaction system call
>
> Also wrong. If you read the gcc documentation you can
> select favouring BSD or SYS5 behaviour at compile time
>
> glibc has the best of both worlds

Non-default behavior is nearly irrelevant. The default
should have matched traditional UNIX and Linux behavior.

The best of both worlds certainly means traditional
signal() and a bsd_signal(), with a non-default option
to choose the BSD signal() behavior.

Re: Question about Linux signal handling

[Alan Cox]

On Sun, 2003-02-23 at 22:29, Albert Cahalan wrote:
> Yes. This is the behavior of all SysV UNIX systems
> and Linux kernels. Unfortunately, BSD got it wrong.

Firstly BSD didn't get it wrong, things merely diverged
historically after V7 unix.

> Worse, the glibc developers saw fit to ignore both
> UNIX history and Linus. They implemented BSD behavior
> by making signal() use the sigaction system call

Also wrong. If you read the gcc documentation you can
select favouring BSD or SYS5 behaviour at compile time

glibc has the best of both worlds

Re: Question about Linux signal handling

[Magnus Danielson]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Question about Linux signal handling
Date: 23 Feb 2003 23:43:31 +0000

> On Sun, 2003-02-23 at 22:29, Albert Cahalan wrote:
> > Yes. This is the behavior of all SysV UNIX systems
> > and Linux kernels. Unfortunately, BSD got it wrong.
> 
> Firstly BSD didn't get it wrong, things merely diverged
> historically after V7 unix.

The V7 signals where not reliable and there where not neatly blockable.
Naturally people invented incompatible solutions to come around it, just as
you would expect.

Cheers,
Magnus - porting teaches you stuff you didn't want to know about

Re: Question about Linux signal handling

[Alan Cox]

On Sun, 2003-02-23 at 23:04, Albert Cahalan wrote:
> > Firstly BSD didn't get it wrong, things merely diverged
> > historically after V7 unix.
> 
> BSD is wrong for not choosing a different name
> for the new system call and leaving the old one.

The same is true of System 5. Both of the changes semantics
from V7 unix.

> > glibc has the best of both worlds
> 
> Non-default behavior is nearly irrelevant. The default
> should have matched traditional UNIX and Linux behavior.

Its all in the docs, and to quote one of the smarter managerial
people we had in Red Hat "I can only provide the information, I 
can't make you hear it."

Alan