On Sat, 10 Mar 2001, Richard Chen wrote:
> 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.
Funny, but it's new to me too :) I see the same thing. I thought it has
something to do with immediate restart, but no, the extra fork happens
after the immediate restart. The real pid is located in logs/httpd.pid
or similar.
> I wonder if there is another way to install the sig handler so
> that it is defined inside the final httpd root process.
I'm not sure you can do anything at all in the parent. Once it spawns the
first child, the only thing it does is handling accept() calls and
maintaining the scoreboard so it will know what to do about its kids.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
