On Sat, Mar 10, 2001 at 12:41:25PM +0800, Stas Bekman wrote:
> On Fri, 9 Mar 2001, Richard Chen wrote:
>
> > This is pretty weird situation. I have installed a signal
> > handler in startup.pl which showed that the signal is
> > delivered to a different process!
> >
> > Here are the demo files:
> >
> > $ cat conf/startup.pl
> > #!/usr/local/bin/perl
> > use lib '/usr/local/apache/modules';
> > $SIG{USR2}=sub {
> > print STDERR "Received USR2 signal:\n";
> > print STDERR "In SIG, pid=$$, ppid=".getppid()."\n";
> > };
> >
> > # cat /usr/local/apache/modules/Apache/ChildInit.pm
> > package Apache::ChildInit;
> > sub handler {
> > print STDERR "In ChildInit, pid=$$, ppid=".getppid()."\n";
> > return;
> > }
> > 1;
> >
> > In httpd.conf I have these 2 lines added:
> > PerlRequire conf/startup.pl
> > PerlChildInitHandler Apache::ChildInit
> >
> > After launching the modperl process we have:
> >
> > $ ps -ef|grep http|grep root
> > root 5964 1 0 16:17 ? 00:00:00 /usr/local/apache/bin/httpd
> >
> > $ tail -1 error_log
> > In ChildInit, pid=5965, ppid=5964
> >
> > So the modperl parent process has pid 5964.
> > After sending USR2 signal to the modperl parent process,
> > these lines appear in the error_log file:
> > Received USR2 signal:
> > In SIG, pid=5963, ppid=1
> >
> > So the signal is delivered to the process 5963 instead of the correct 5964.
> >
> > Has anyone seen this before?
> > Is this a bug in modperl or if the procedure for installing the handler
> > is incorrect?
>
> I think that it has nothing to with mod_perl, it's the OS that handles
> pizza^H^H^H^H^Hsignal deliveries.
>
> BTW, what kind of process 5963 was? How come that if it wasn't the httpd
> process you have installed the signal handler in, it knew to print the
> stuff to the error_log which it has never opened? looks like you are not
> getting the parent process pid correctly.
>
> You also didn't tell, how did you send the signal.
>
I think the problem is with the procedure of installing the handler.
I did not know what kind of process 5963 was because it did not
show up in the ps command even within the sig handler. But now
I caught it by modifying the startup.pl routine to show the pid
when the sig handler is defined:
$ cat startup.pl
#!/usr/local/bin/perl
use lib '/usr/local/apache/modules';
print STDERR "In startup, pid=$$\n";
$SIG{USR2}=sub {
print STDERR "Received USR2 signal\n";
print STDERR "In SIG, pid=$$, ppid=".getppid()."\n";
};
Now here are the steps to show the problem
Start up the modperl server:
# ../bin/httpd -d /usr/local/apache
In startup, pid=11525
This means that at the time when the sig handler is defined, pid=11525.
However, the ps command shows a different pid for modperl:
# ps -ef|grep http|grep root
root 11526 1 1 08:28 ? 00:00:00 ../bin/httpd -d /usr/local/apach
# tail -1 ../logs/error_log
In ChildInit, pid=11527, ppid=11526
The above clearly shows that the httpd server has pid 11526,
not 11525. This means that process 11525 started by the startup
procedure immediately exits after forking the real httpd process 11526.
Now we send signal to the httpd server:
# kill -USR2 11526
And here are the lines recorded in error_log:
# tail -2 ../logs/error_log
Received USR2 signal
In SIG, pid=11525, ppid=1
So clearly the signal handler still remembers that at
the time when it was defined, the pid was 11525, not 11526
for httpd.
Apparently modperl did some preparatory work before forking out
the real httpd. This is something new to me.
I wonder if there is another way to install the sig handler so
that it is defined inside the final httpd root process.
Thanks for your help.
Richard
