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!

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

I've had prominent personal experiences with that effect since, oh, around 1971 sometime I think!

What I was hoping to get out of the original post was whether there were known gotchas, easy ways to mess this up and get this symptom. I find it's worth checking, when one can, for this sort of thing.

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.

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