in reply to Re: SIGHUP with Proc::Daemon
in thread SIGHUP with Proc::Daemon

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

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

Replies are listed 'Best First'.
Re^3: SIGHUP with Proc::Daemon
by jaandy (Acolyte) on Mar 09, 2012 at 19:18 UTC
    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); }

    after I sighup it, I get:
    got hup got message $VAR1 = \undef;


    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
      Its kinda weird that SIGHUP makes $sock->recv() return

      Actually, in this particular case, it's a plus, because it gives you the opportunity to do the reloading of the config before restarting the recv.

Re^3: SIGHUP with Proc::Daemon
by Eliya (Vicar) on Mar 09, 2012 at 19:13 UTC

    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")