Re: How to run POE as a daemon

[hossman]

I can get this program to run by nohupping/backgrounding it, but I'd really like get this program to run as a daemon.

Your wording there makes me think that perhaps you don't understand hwat it is you are aking for.

Any program which when run, sits and waits for input can be considered a simple daemon. When you say that if you nohup and/or background it it works, i get the impressing tha the daemon is working just fine -- it's only when you log out that it dies -- which is true of a lot of things that can still be considered daemons.

I think the real question you want to be asking is "how can I make my daemon detach itself from its parent?"

This link in particular looks interesting.

[rah]

This is not a daemon:

while (1) {
  print "Enter a number: ";
  $Number = <STDIN>;
  chomp($Number);
   print "You entered - $Number.\n";
  }

yet you would have me believe it is.

When I said daemon, I meant having true daemon characteristics, not kinda sorta daemon-like. Fork and exit, setsid, chdir /, close or redirect STDIN, STDOUT, STDERR. Here's the example from Matt Sergeants' talk:

Daemonizing POE

• We often write daemons with POE (network daemons, cron daemons, etc
• But POE doesn't "background" automatically, so we need to write that:

use POE;
use POSIX;
$|++;
sub become_daemon {
my $child = fork;
die "Can't fork: $!" unless defined($child);
exit(0) if $child; # parent dies;
POSIX::setsid(); # become session leader
open(STDIN,"</dev/null");
open(STDOUT,">/dev/null");
open(STDERR, '>&STDOUT');
umask(0); # forget file mode creation mask
$ENV{PATH} = '/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
}
become_daemon(); # MUST do this before we create any sessions
POE::Session->create(
inline_states => {
_start => sub { $_[KERNEL]->yield("loop") },
loop => sub { $_[KERNEL]->delay_set("loop", 10) },
});
$poe_kernel->run();
exit(0);

This example fails in the same way: POE::Kernel's run() method was never called.

[Matts]

It doesn't fail. The warning "POE::Kernel's run() method was never called" is from the fact that the parent exits without having ever called $poe_kernel->run(), which is absolutely fine because the child continues and does that. It's just a warning. Ignore it. That warning should be gone in POE 0.23.

[hossman]

This is not a daemon:

while (1) {
    print "Enter a number: ";
    $Number = <STDIN>;
    chomp($Number);
    print "You entered - $Number.\n";
}

yet you would have me believe it is.

No, I don't consider that a daemon because it's actively soliciting information on a handle (or port, or file, etc...) as soon as it starts. I would however consider this to be a very simple daemon...

while (1) {
    $Number = <STDIN>;
    chomp($Number);
    print "You entered - $Number.\n";
}

...because it passively waits for a connection on a handle (or port, etc...) before doing anything. it's not a very useful daemon because it's single threaded ... but lots of daemons can run as single threads.

But none of this is really helping you achieve what you want, so i guess we'll just agree to disagree.

In the mean time, perhaps Proc::Daemon would be of interest to you?

[Anonymous Monk]

I have no idea what POE is but that code is already dodgy to begin with. Perhaps this is a usage I'm not familar with but I'd normally write open(STDERR, '>&STDOUT'); as *STDERR = *STDOUT instead. There are no  or die "Couldn't open ...: $!" tests on the open() calls. It'd be interesting if you'd stick some print() calls around that script and let us know which line it's cheffing on.

[Matts]

Please log in if you wish to comment on somebody's code looking "dodgy". Yes, this is a usage you're not familiar with. Please read perldoc -f open. The "or die" is skipped because this is for a presentation - it has to fit on a slide and be visual and understandable by the attendees in the few seconds that I have to show it to them. Plus if you can give me a reason they might fail on a unix system I'll be a lot more interested in your comment ;-)