Code Comments
Programming Forum and web based access to our favorite programming groups.Hi perl-people,
I'm not sure if this is beginners stuff, but I'll post here 'cause
it's the only list I'm subscribed to at the moment.
I'm writing a script that will daemonize itself, and then watch some
processes. If one of those processes die, it will start it again.
So, I've been reading the perlipc docs and I found this handy code on
proper daemonization:
use POSIX 'setsid';
sub daemonize {
#it's polite for daemons to chdir to root so that they
#don't prevent a filesystem from being unmounted
chdir '/' or die "Can't chdir to /: $!";
#it's also polite for daemons to redirect all output to
#/dev/null so users don't get random output
open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
open STDOUT, '>/dev/null' or die "Can't write to /dev/null:$!";
#the parent get's the new child's pid back, the child gets '0' back
defined( my $pid = fork ) or die "Can't fork: $!";
#here's where I start having problem. This code assumes that
#the parent will be exiting, thus leaving the child able
#to run setsid
exit if $pid;
setsid or die "Can't start a new session: $!";
open STDERR, '>&STDOUT' or die "Can't dup STDOUT: $!";
}
perlipc goes on to explain:
"The fork() has to come before the setsid() to ensure that you
aren't a process leader (the setsid() will fail if you are).
So, my question is, how do I implement this code WITHOUT the parent
process dieing?
--Errin
Post Follow-up to this messageOn Thu, 23 Sep 2004 11:23:16 -0500, Errin Larsen <errinlarsen@gmail.com> wrote: > Hi perl-people, <<SNIP>> > So, my question is, how do I implement this code WITHOUT the parent > process dieing? > > --Errin > I found that (at least on the Solaris OS that I'm working on) that the setsid function will setup a new session UNLESS: " The calling process is already a process group leader, or the process group ID of a process other than the calling process matches the process ID of the calling process. " So, I think that's saying that as long as the process (the child) does not have any children of it's own, then I'll be ok with the above code! Is that what the blurb above is saying? (Why are UNIX docs always so darn hard to read!!?)
Post Follow-up to this message> Hi perl-people,
>
> I'm not sure if this is beginners stuff, but I'll post here 'cause
> it's the only list I'm subscribed to at the moment.
>
A stretch, but there have been more complex topics discussed. This is
pretty much a catch all and some of the experts will probably appreciate
not answering the same how do I delete an element of an array question :-).
> I'm writing a script that will daemonize itself, and then watch some
> processes. If one of those processes die, it will start it again.
> So, I've been reading the perlipc docs and I found this handy code on
> proper daemonization:
>
Great docs... however...
> use POSIX 'setsid';
>
> sub daemonize {
> #it's polite for daemons to chdir to root so that they
> #don't prevent a filesystem from being unmounted
> chdir '/' or die "Can't chdir to /: $!";
>
> #it's also polite for daemons to redirect all output to
> #/dev/null so users don't get random output
> open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
> open STDOUT, '>/dev/null' or die "Can't write to /dev/null:$!";
>
> #the parent get's the new child's pid back, the child gets '0' back
> defined( my $pid = fork ) or die "Can't fork: $!";
>
> #here's where I start having problem. This code assumes that
> #the parent will be exiting, thus leaving the child able
> #to run setsid
> exit if $pid;
> setsid or die "Can't start a new session: $!";
>
> open STDERR, '>&STDOUT' or die "Can't dup STDOUT: $!";
> }
>
> perlipc goes on to explain:
> "The fork() has to come before the setsid() to ensure that you
> aren't a process leader (the setsid() will fail if you are).
>
> So, my question is, how do I implement this code WITHOUT the parent
> process dieing?
>
> --Errin
>
Actually you want the parent process to "die"... or at least exit, then
your child process is the session leader and will do everything else you
need, aka fork more children in your case. Essentially you want to make
it so that the tty/shell (whatever) no longer thinks it has absentee
children so that it can exit cleanly, by daemonizing your process
essentially becomes a child of the kernel, which will always be running
(until shutdown that is).
However, the best advice NOT given by perldoc perlipc is to use the
Proc::Daemon::Init module, it is incredibly easy and takes care of all
of the code you mention above by itself, in a neat package that you
don't have to worry about the internals of. It is available through
CPAN as usual, and despite its incredibly "low release number" (if you
are into that hole thing) I have never had problems with it.
Two additional comments, that you are likely to stumble across:
1. How do I get back to my process after it has daemonized, how do I
stop it, etc?
This is where you will likely want to get into writing a "pid" file to
the disk so that your process can be looked up and signaled, and/or to
prevent two copies of your daemon running, or at least trying to work on
teh same resources.
2. How do I do logging, etc.?
Check out the very, very excellent Log::Log4perl suite, it is incredible
and can accomplish just about all of your logging needs.
Of course I have already mentioned POE.... but I will plug it again.
http://danconia.org
Post Follow-up to this message> On Thu, 23 Sep 2004 11:23:16 -0500, Errin Larsen <errinlarsen@gmail.com> wrote: > > <<SNIP>> > > > I found that (at least on the Solaris OS that I'm working on) that the > setsid function will setup a new session UNLESS: > " The calling process is already a process group leader, > or the process group ID of a process other than the > calling process matches the process ID of the calling > process. " > > So, I think that's saying that as long as the process (the child) does > not have any children of it's own, then I'll be ok with the above > code! Is that what the blurb above is saying? (Why are UNIX docs > always so darn hard to read!!?) > That is the way I read it, though see the suggestion in my other post... http://danconia.org
Post Follow-up to this messageOn Thu, 23 Sep 2004, Errin Larsen wrote: > [....] I was looking for a daemon that would run, start other servers, > and that hang around monitoring them. In other words, you want something that works like apache [1.x]. * To launch Apache, you run apachectl, a shell script. * apachectl launches a parent httpd process, which in turns spawns a pool of listener httpd child processes. * apachectl goes away then, and the parent httpd supervises the operation of the server from then on. Granted, the interesting bits are all done in C or something, so that may not help you here, but it's the model you're looking for. -- Chris Devers
Post Follow-up to this message> On Thu, 23 Sep 2004, Errin Larsen wrote: > > > In other words, you want something that works like apache [1.x]. > > * To launch Apache, you run apachectl, a shell script. > > * apachectl launches a parent httpd process, which in turns spawns > a pool of listener httpd child processes. > > * apachectl goes away then, and the parent httpd supervises the > operation of the server from then on. > > Granted, the interesting bits are all done in C or something, so that > may not help you here, but it's the model you're looking for. > > > > -- > Chris Devers > If you really want to get into it, Network Programming with Perl has excellent coverage of various common types of daemons and how to write them in Perl. Don't know if you have the resources or time but it is worth a look if the interest is there. My very unprofessional and non-expert review of it is here: http://danconia.org/cgi-bin/request...k;id =26 http://danconia.org
Post Follow-up to this message
Show a Printable Version
Email This Page to Someone!
Receive updates to this thread
Powered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.