Steve Hay wrote:
I notice that running tests via nmake test, t/TEST or t/SMOKE leaves a httpd.pid file behind in t/logs after the server has stopped. Is this supposed to happen? I thought Apache normally deleted the httpd.pid file when it is stopped.
That's not under Apache-Test's control, it's Apache who manages this file, we aren't supposed to touch it. All we do is reading the pid from it.
Well that's odd then, because when I start & stop my installed Apache2 server myself, the httpd.pid file that it creates in C:\apache2\logs *does* get deleted. I wonder why that doesn't happen to mp2's t\logs\httpd.pid when the testing code starts & stops it?
I also find that if there is such a httpd.pid file in place from some previous run then t/SMOKE generates an error on my Windows machine because it tries to `cat ...` the file to get the PID to kill, and "cat" isn't available on Windows (unless Cygwin tools or similar are in the PATH), e.g.:
My bad, though if we are alredy returning if the file has failed to open, this line is redundant then, no?
return unless -f $file;
Yes, I guess so, but it just seemed to make more sense to not try to open a file if it doesn't exist. Excessive paranoia on my part I expect.
> - my $pid = `cat $file`; > - chomp $pid; > + open my $fh, '<', $file or return; > + chomp(my $pid = <$fh>); > + close $fh or return;
and close should always succeed or die if you choose to check the return code. I can't see why would you want to silently return on failing close.
So you're saying "close $fh or die ...", yes? I suppose that makes more sense. (It's probably just more excessive paranoia in even checking the return code, but I always tend to so.)
The attached patch removes the use of "cat" to read any existing httpd.pid file.
But I still have a problem with the httpd.pid file being left behind in the first place. Windows OS's are terrible for re-using the same PID's over and over again within a short space of time, so if a PID file has been left behind from an Apache that has long since stopped then we don't want the next t/SMOKE trying to kill that PID because there's a good chance that it now relates to some other process entirely!
That PID file definitely needs to be cleaned up properly when the Apache used for the tests shuts down. The kill_proc() function that I've just supplied a patch for should only be trying to kill anything on the rare occasions that an Apache actually is still running!
Understood. But there could be other Apache versions running, you don't want to kill just any Apache process. Can we take the pid and check whether it's an apache process before trying to kill it?
My thinking was that the PID file should be cleaned up by Apache when it shuts down normally, so that then if we do ever find a PID file left behind then we can be condifdent that it relates to an Apache that didn't shut down normally which we can now try to kill.
But I guess that isn't even true. Maybe the Apache from a previous test is still running and needs killing, but maybe it died abnormally, leaving its PID file behind. In that case, who knows what process might now be using that PID? It is possible with Win32-specific code to find out if a process with that PID exists, and if it is an Apache process (i.e. called Apache.exe), and even which Apache it is (on the basis of the path to the Apache.exe). For example, we can use the GetProcInfo() routine in Win32::Process::Info (see http://search.cpan.org/~wyant/Win32-Process-Info-1/Info.pm): This little program gets a hash of information about my installed Apache1 process:
use Win32::Process::Info; my $pi = Win32::Process::Info->new(); open my $fh, '<', 'C:\\apache\\logs\\httpd.pid'; chomp(my $pid = <$fh>); close $fh; (my $info) = $pi->GetProcInfo($pid);
The hash %$info contains tons of stuff about the process, including:
Name => Apache.exe ExecutablePath => C:\apache\Apache.exe CommandLine => "C:\apache\Apache.exe" --ntservice CreationDate => 1065695628
but that's all very Win32-specific, even Win32::Process::Info isn't even part of the libwin32 distro. I don't know how to do this more generally.
- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
