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.

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]

$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.