HappyPerlUser wrote:
HappyPerlUser wrote:
Have now unchecked the enable interact with desktop checkbox, although I
thought we needed that for some automation scripts in the past (that ran
external windows programs on the server).
May also try running Apache from the command line, but then again as you
say it is then a different user, and quite different from running as a
service.
This server is not part of a domain. Maybe we just need to remove the
mod_auth_sspi module {probably a hang over from another system}.
Removed mod_auth_sspi module. It was a hang over. No change in behavior.
Despite the enable interact with desktop being unchecked, the popup messages
still seems to be appearing on the admin console (need to confirm this)
Running Apache from the command line and disabling our watchog did give us
some further information.
Stared httpd.exe: no output and normal service started. Requests were
serviced normally
Initially there were 2 windows processes: PID 3748 & 9000
After the server stalled, the popup appeared on the terminal server and no
further requests were serviced.
Upon hitting the OK button on the popup, there were still 2 windows
processes, but now they were PID 3748 1580
Again server stalled and a popup appeared. No web requests serviced. After
clicking OK requests were serviced again normally. Now the PIDs are 3748 and
3556.
No messages ever appeared on the Windows cmd window running the httpd.exe
process (presume this meant that nothing was sent to stderr or stdout).
No crash dump was ever created, even though I had userdump configured to
monitor the process.
So it looks like something inside Apache is causing the popup and then
attempting to recover internally by regenerating a new worker process.
Could this be related to config parameters???
# Turn on library reload mechanism
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload
I'd like mod_perl to auto-reload, but I'd like it to do that without waiting
for the OK button on the windows popup.
You probably know this, but just in case : the Apache2::Reload module /should/ have
nothing to do with the fact that the Apache server restarts after a crash. It's function
is to trigger a reload of a perl library module, if it notices that the module file has
changed on the disk since it was first loaded.
I am not sure how exactly it does that, but it is possible that in the case of Windows, it
does that by forcing a global "Apache reload" (aka kill the Apache children/threads and
restart them, which will force a reload of the Perl interpreter(s) etc..).
Also, as you might imagine, doing this means that it has to check the module files on disk
regularly, so it will cost some overhead. I would use this on a development server (where
modules might change frequently), but not on a production server (where they should change
only occasionally, and when they do, you should know and can do a manual Apache reload).
Under Windows, Apache starts 2 processes : one is the "main" Apache (similar to the Linux
case), and the other one is the "children" (in the forms of threads) which actually
process the requests. That's why you see 2 PID's.
But then, there are the following notes :
http://search.cpan.org/~phred/mod_perl-2.0.5/docs/api/Apache2/Reload.pod#Threaded_MPM_and_Multiple_Perl_Interpreters
These notes lead me to suspect that, perhaps, there /is/ a relationship between your usage
of Apache2::Reload and the errors you are seeing. Such as perhaps if one of the
applications uses something like these "pseudo-hashes" they are talking about.
In any case, it gives me the general impression that using Apache2::Reload on a Windows
machine may not be the most stable/reliable thing to do.
What happens if you disable Apache2::Reload ?
