I've tried changing the code inside to something simpler

Have you tried setting just a (global) flag variable in the handler, and then doing the reloading elsewhere in the daemon code?  (presumably, you have some loop where you could check the flag...)

Doing a lot of stuff directly in the signal handler sometimes isn't the best idea.

To find out more about why it dies, you might want to attach strace (or the equivalent tool on your platform) to the daemon process before you send it the signal (strace -p <PID>).

Unfortunately I don't think that will be possible. I'm using zeromq in my daemon so the main loop looks like:


while (1)
{
  my $msg = $sock->recv();
  my $data = $msg->data();

  unless ($csv->parse($data))
  ... etc ...
}
[download]


The $sock->recv() blocks until there is a new message.

Hum... I think I'll try putting zeromq into my simple test app. Maybe its not daemons stuff that's causing me problems, maybe its zeromq stuff. Thanks for the idea.

-Andy

System calls that may take a "long time" (such as accept, recv, etc.) are normally interrupted by a signal, and in case resuming isn't handled automatically (some systems don't), it might well be the cause of the problem (e.g. subsequent code failing due to not having the expected data...)

See also signal(7) (section "Interruption of System Calls")

Woot! Its zeromq stuff. My new test app:



#!/usr/bin/perl

use common::sense;
use ZeroMQ ':all';
use Data::Dumper;

my $ctx = ZeroMQ::Context->new();

my $sock = $ctx->socket(ZMQ_PULL);
$sock->setsockopt(ZMQ_HWM, 500);
$sock->bind('tcp://*:5558'); 

$SIG{HUP}  = sub {
  print "got hup\n";
};

while (1)
{
  my $msg = $sock->recv();
  print "got message\n";
  print Dumper(\$msg);
}
[download]


after I sighup it, I get:


got hup
got message
$VAR1 = \undef;
[download]



In real code, I call $msg->data() next which when $msg is undef I can see that killing the script.

Its kinda weird that SIGHUP makes $sock->recv() return, but at least I can code around that.

thanks again,

-Andy