Re^2: Why this daemon can only receive the HUP signal no more than one time?

Yes, indeed!

The daemon will blocked the SIGHUP signal when it execute the SIGHUP handler. And after it relaunch itself in the handler, the SIGHUP remains being blocked, so the SIGHUP sent later is pending.

Put the following code at the head of the scrpit:

 my $emptySigSet = POSIX::SigSet->new();
 my $oldSigSet = POSIX::SigSet->new();
 POSIX::sigprocmask( &POSIX::SIG_BLOCK, $emptySigSet, $oldSigSet );

 if ( $oldSigSet->ismember( &POSIX::SIGHUP ) ){
     print "SIGHUP is blocking.\n";
 }else {
     print "SIGHUP is not blocking.\n";
 }
[download]

And replace the old hupMain with the following new one:

 sub hupMain {

     while (1) {
         print "Running hup main function.\n";
         sleep 3;
         my $pendingSigSet = POSIX::SigSet->new();
         POSIX::sigpending( $pendingSigSet ) ;
         if ( $pendingSigSet->ismember( &POSIX::SIGHUP ) ){
             print "Pending signal set contains SIG_HUP\n";
         }
     }
 }
[download]

I can observe the SIGHUP signal is being blocking and pending.

Comment on Re^2: Why this daemon can only receive the HUP signal no more than one time? Select or Download Code

Replies are listed 'Best First'.
Re^3: Why this daemon can only receive the HUP signal no more than one time? by lifeboat (Initiate) on Apr 05, 2017 at 09:34 UTC
Based on Re: Can't catch signals after an exec?, change your code `$SIG{HUP} = \&doSigHup;` [download] to: `use POSIX (); $sigset=POSIX::SigSet->new(); $action=POSIX::SigAction->new('doSigHup',$sigset,&POSIX::SA_NODEFER); POSIX::sigaction(&POSIX::SIGHUP, $action);` [download]	[reply] [d/l] [select]
Re^4: Why this daemon can only receive the HUP signal no more than one time? by Anonymous Monk on Apr 05, 2017 at 17:38 UTC
`$action=POSIX::SigAction->new('doSigHup',$sigset,&POSIX::SA_NODEFER);` Note that you are setting up an "unsafe" signal, as opposed to Safe Signal that original poster was using. Furthermore, the use of `SA_NODEFER` to avoid changes to sigprocmask has the unfortunate side-effect of making your handler re-interruptable from within its own signal handler. Altogether, a particularly nasty concoction that may eventually result in data corruption. I'd rather advise to just clear the blocked signal at program (re)start, after the handler is assigned of course.	[reply] [d/l] [select]