apache2 and system ... cotinued from 2004

holandes777 has asked for the wisdom of the Perl Monks concerning the following question:

The original title was "apache2 and system", # 394424.

I'm trying to write a page that starts and stops a daemon. The symptom is that apache goes away and never comes back. Further actions on the page leave defunct processes in ps -ef (the called program or parent).

The original post was spot on for what I needed, so I tried it with different sleep times as the process to run.

The code is below. The amount of time ($tdiff) is always very low (about 0.004), however, the time apache "goes away" is directly proportional to the amount of time I set the sleep interval for (1, 10, 100).

It looks like perl finishes quickly, but apache does not return the page until all child processes finish, even if the perl process has.

Any advice on what to do to get the page back immediately?

#!/usr/bin/perl

use strict;
use Time::HiRes qw (usleep time gettimeofday);
use CGI qw/:standard *table start_ul use_named_parameters/;     # load
+ standard CGI routines
use CGI::Carp qw /fatalsToBrowser/;

print "Content-Type:text/html\r\n\r\n";
print "<HTML>\n";
print "<HEAD></HEAD>\n";
print "<BODY>\n";
print "<CENTER>\n";
my $sleep = 100;
my $t1 = time;
print "using sleep of $sleep<BR>\n";
print "start time $t1<BR>\n";

# this was taken from the 2004 example vvvvvvvvvvvvvv
my $pid = fork;
die "Error forking: $!" unless defined $pid;
if (!$pid) {
    my $pid = fork;
    die "Error forking: $!" unless defined $pid;
    if (!$pid) {
        exec("sleep $sleep &");  # << except for this, changed from "f
+oo"
    }
    else {
        CORE::exit;
    }
}
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

my $t2 = time;
my $tdiff = $t2 - $t1;
print "end time $t2<BR>\n";
print "difference = $tdiff<BR>\n";
print "</CENTER>\n";
print "</BODY>\n";
[download]

Comment on apache2 and system ... cotinued from 2004 Download Code

Replies are listed 'Best First'.
Re: apache2 and system ... cotinued from 2004 by ikegami (Patriarch) on Aug 18, 2009 at 14:10 UTC
You don't close STD*. `setsid` is usually called too. Net::Server::Daemonize	[reply] [d/l]
Re^2: apache2 and system ... cotinued from 2004 by holandes777 (Scribe) on Aug 18, 2009 at 20:49 UTC
Net::Server::Daemonize worked like a charm! Thank you!	[reply]
Re: apache2 and system ... cotinued from 2004 by holandes777 (Scribe) on Aug 20, 2009 at 18:18 UTC
This is not strictly related but the answer may help others so I'll ask here: Net:Server::Daemonize writes a .pid file with the process number. Very useful becasue one can read that and then do a kill -2 (that process #) to stop the daemon (the .pid file is deleted as well). BUT ... I am having permissions problems with reading and writing the .pid file when I execute through apache. I'm running apache on ubuntu. The daemos runs from /usr/lib/cgi-bin. The apache user is www-data. I created a subdirectory /usr/lib/cgi-bin/pids and did a sudo chown www-data:www-data pids plus sudo chmod 777 pids. The daemon dies at startup (even from the command line). May I request help? Where should I be writting the pids to?	[reply]
Re^2: apache2 and system ... cotinued from 2004 by afoken (Chancellor) on Aug 22, 2009 at 16:04 UTC
I would delegate daemon management to an external tool, like daemontools. As a nice side effect, this completely eliminates the need for PID files. The apache handler would simply invoke the `svc` command with proper arguments, e.g. `system('/command/svc','-u','/service/mydaemon')`, or more likely, invoke it via sudo so apache does not run as root: `system('/usr/bin/sudo','/command/svc','-u','/service/mydaemon')`. The daemon does not need any daemonizing code, you write it as a simple foreground command line tool, the daemontools take care of managing the process, including backgrounding, error logging, signals, restarts, changing user and group id, environment, and so on. See http://thedjbway.org/daemontools.html for a human readable introduction. (And please don't chmod 777 any file or directory without a VERY good reason, especially not on systems connected to any kind of network.) Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]