dd-b has asked for the wisdom of the Perl Monks concerning the following question:

I'm daemonizing my command proxy (now) using Proc::Daemon::Init(). And it promptly goes away.

Daemonizing closes all open file descriptors. I do it just before initializing logging, and I'm getting logging to happen. I've disabled the logging config that used to log to the console (Log::Log4perl) but am still logging to my log file. I'm trapping signals INT, TERM, and USR1, and ignoring PIPE. I don't have anything trying to do stdio that I can find.

I'm going to ramp up the logging and see what I can learn, but what could be going on? "This was supposed to be simple" :-) . Would console output abort the process? Would Perl attempting to send a warning abort the process?

Added: got it, thanks! Path problem; daemonize also changes default directory to /, and that makes a mess of a lot of things in my logging and other config files.

Replies are listed 'Best First'.
Re: Daemon dies instantly
by Eliya (Vicar) on Oct 14, 2011 at 23:02 UTC

    strace is usually of great help in such cases... 

    $ strace -f ./your_proxy.pl

    [download]

    And if you suspect the issue is file related, you can increase the signal/noise ratio with 

    $ strace -f -efile ./your_proxy.pl

    [download]
[reply]
[d/l]
[select]
Re: Daemon dies instantly
by GrandFather (Saint) on Oct 14, 2011 at 22:54 UTC

    Show us the code! Better still, show us a small sample script the demonstrates the problem.

    True laziness is hard work
[reply]

      Okay, here's a code excerpt. I see message "log init a", I do not see message "log init b". 

      
# Daemonizing closes all fds, so must be before log init.
# (Which means it's hell to tell why it later aborts.)
if ($daemonize) {
    Proc::Daemon::Init();
}

open (my $xxx, ">/nfshome/ddb/p/kcmdproxy/elog.log") or die "Open fail
+ed: $!";
print $xxx "opened log file\n";

# Higher-level non-error logging level
Log::Log4perl::Logger::create_custom_level('NOTIFY', 'ERROR');
print $xxx "log init a\n";
Log::Log4perl->init_and_watch($logconfig, 'HUP');
print $xxx "log init b\n";

      [download]

      When not daemonizing, it gets through all this and more (the old code works in non-daemon mode). When I daemonize, it dies when I do the log config. And I know why; the default $logconfig is a relative path, and daemonizing sets current directory to /.

      As you may gather, I figured that out as I was writing the description.

      Thanks!

[reply]
[d/l]
        As you may gather, I figured that out as I was writing the description.

        Good work dd-b++. And that is why we encourage honing the problem description and sample script - most often you'll figure it out for yourself along the way. ;)

        True laziness is hard work
[reply]

      So you're saying there are no obvious ways people do this to themselves? What about my two specific questions about things that might try to talk to STDERR? Would either of those kill the daemon?

      The whole code is up over 700 lines at this point, which seems entirely excessive to ask people to grope through. I'm reasonably certain that the simplest case will not reproduce the problem (that would mean Proc::Daemon and Log::Log4perl were incompatible, and there's lots of evidence of people using them together). So I'm working down, rather than up, in this case, and that's going to be slower.

[reply]

        Yup, 700 lines is far too much to post, but I'll bet you can cut out 1/2 those lines without affecting the bug. The trick is finding the lines that can be removed. Oh, and when you done the first pass and removed 1/2 the lines, do it again and keep doing it until there are no more lines to remove without the bug disappearing!

        It's called a binary search and is useful for more than just searching data. ;)

        True laziness is hard work
[reply]

Back to Seekers of Perl Wisdom