On Tue, 14 Oct 2003, Stas Bekman wrote:
Steve Hay wrote: [...]
Would it be possible to change TestSmoke to create a TestServer object and call the start() and stop() methods on it, rather than using "t/TEST -start" and "t/TEST -stop", or is that a really stupid question?
As someone said, there are no stupid questions ;)
Sure, we can do that, but what would be the gain? TestSmoke really doesn't want to be complicated and wants to delegate all control to TestServer. All it does is parsing TestRun's output. So if anything that needs to be fixed is TestServer. TestSmoke should just be able to say, ok start the server, and then please run this test, and then please stop (without ever needing to repeat the command, "I said stop already!").
If you suggest the same thing for TestRun/Server, remember that anybody can issue t/TEST -start/-stop from the outside, rendering the object approach useless (since -stop it won't have an access to the object created by -start, as the request is coming from theoutside)
p.s. I'd let you guys figure it out on win32 and once you are happy we will see how to make that behavior similar on other platforms. Of course if you need to change things in the non-win32 area, please do so. As mentioned before the left over pid file happens on unix as well, but it's not a critical issue there, since unices rotate pids and don't immediately re-use them.
I'm not sure there is a complete solution here ... That's a good point, Stas - the changes have to go into TestServer.pm, as someone can run t/TEST in the same way as t/SMOKE. And so we can't rely on the Win32::Process object being available. However, if we fall back to using t/logs/httpd.pid, then in some circumstances this pid may have been recycled to another process, and killing that wouldn't be good ... We could look up the process info using Win32::Process::Info, but that module's not included by default on ActivePerl.
I think Steve has a good point that, on Win32, it's a bit
too dangerous to go around killing processes that may not
be Apache ones.
I completely agree with Steve, I wasn't objecting to this point ;)
Given that, it seems to me better to use Win32::Process::Info to get the name of the process, and kill that if the name is 'Apache.exe' (of course, this isn't foolproof, as it may be a legitimate Apache process started from somewhere else, but one has to draw a line ..). Stas, would you object to making Win32::Process::Info a requirement on Win32 for Apache-Test? I'll supply ppm versions of it (and also the required Win32::API), so for most users it should be easy to install.
Can we try first to see if we can get away without making A-T depend on Win32::Process::Info? If anything else fails, than it's OK I guess.
How about the following approaches:
1) after attempting to kill httpd, remove the pid file no matter what. If the process wasn't killed, so be it, the user will have to kill it manually. (he will know that since the port won't be available)
2) try to use 'httpd -k stop' on httpd 2.0, which should do a clean stop, removing the httpd.pid file. That won't work on 1.3, where we may be able to use (1). I remember you have mentioned that Apache.exe -k doesn't work?
I've attached two patches - one using Win32::Process::Info and one not - perhaps we could choose one and refine it ... There's one non-Win32 modification made - to the kill_proc() sub of TestSmoke, where `cat $file` is replaced by an explicit open and read.
sure, the cat got be killed for the sake of portability ;)
p.s. I won't comment on the patch at the moment, in hope that we can do it in a different way, without creating extra deps on external packages.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
