Re: Errors while using graceful shutdown
I could fix this with some modifications to mod_cgid.c. I found that the httpd process serving the CGI request tries to contact the daemon in the cleanup callback even when a graceful restart has been issued. A check for a graceful restart situation should be made before the connect. The following condition at the beginning of cleanup_script() solves the problem : if (ap_graceful_stop_signalled()) return APR_EGENERAL; Regards, Kiran Brian Akins wrote: Kiran Mendonce wrote: For every concurrent request issued, there seems to be an error. I think this is because ab closes the last set of connections without completing the HTTP "transaction." We noticed this on some of our apps. This may or may not be your issue as well.
Errors while using graceful shutdown
Hi, While running the bench marking tool, ab (options are -c 30 -n 400), on a cgi script that takes about 30 seconds to complete, I notice the following error in the logfile when I do a graceful shutdown. This is on 2.0.55 version of Apache. The error I get is : [Thu Mar 02 17:23:11 2006] [error] [client 15.42.227.146] daemon couldn't find C GI process for connection 5 [Thu Mar 02 17:23:11 2006] [error] [client 15.42.227.146] daemon couldn't find C GI process for connection 67 For every concurrent request issued, there seems to be an error. I noticed that CGI daemon dies immediately after a graceful shutdown is issued and the message is printed by the other httpd children that were spawned before the graceful shutdown is issued. Any idea why this should happen ? Thanks, Kiran
Re: How to determine if a graceful restart is initiated from within a module
Hi Colm, We have a customer who wants cgi scripts to be killed after a graceful restart after 'some' time. So I am implementing a timer that will be configurable so that after that time has elapsed cgid can terminate the child cgi processes that are still around. For that I need to know if it is a graceful restart and I am looking at ways of getting that information. Regards, Kiran Colm MacCarthaigh wrote: Apologies for the late reply, I was actually looking at this codeyesterday, and no there is no convienent way to do it, but why is thatyou want to ?It'll take some form of IPC to do this, but I'm shortly about to startwriting a complete replacement for mod_cgid which we may or may not endup using, so it'd be useful to have feedback on why you need to do thisand what additional requirements we can try and fulfill.On Thu, Nov 24, 2005 at 06:17:34PM +0530, Kiran Mendonce wrote: I wanted to add that I am working om mod_cgid and thats where I want to check if it is a graceful restart. I did some more investigation and found that listener_may_exit is not set during a graceful restart for cgid which is why ap_graceful_stop_signalled() does not return 1. Is there any way I can find if it is a graceful restart in mod_cgid ?Thanks and Regards,KiranKiran Mendonce wrote: Hi,I'd like to know how a module can determine if a graceful restart has been issued. I tried using the ap_mpm_query() and the ap_graceful_stop_signalled() APIs but I have'nt really been able to get what I want. ap_mpm_query() always returns 0 on graceful/restart/stop conditions and ap_graceful_stop_signalled() does not return 1 on graceful restart.So I'm confused what to do. Any suggestions ?Thanks and Regards,Kiran
Re: How to determine if a graceful restart is initiated from within a module
I wanted to add that I am working om mod_cgid and thats where I want to check if it is a graceful restart. I did some more investigation and found that listener_may_exit is not set during a graceful restart for cgid which is why ap_graceful_stop_signalled() does not return 1. Is there any way I can find if it is a graceful restart in mod_cgid ? Thanks and Regards, Kiran Kiran Mendonce wrote: Hi, I'd like to know how a module can determine if a graceful restart has been issued. I tried using the ap_mpm_query() and the ap_graceful_stop_signalled() APIs but I have'nt really been able to get what I want. ap_mpm_query() always returns 0 on graceful/restart/stop conditions and ap_graceful_stop_signalled() does not return 1 on graceful restart. So I'm confused what to do. Any suggestions ? Thanks and Regards, Kiran
How to determine if a graceful restart is initiated from within a module
Hi, I'd like to know how a module can determine if a graceful restart has been issued. I tried using the ap_mpm_query() and the ap_graceful_stop_signalled() APIs but I have'nt really been able to get what I want. ap_mpm_query() always returns 0 on graceful/restart/stop conditions and ap_graceful_stop_signalled() does not return 1 on graceful restart. So I'm confused what to do. Any suggestions ? Thanks and Regards, Kiran
Re: piped log bug?
Hi Arkadi, We've run into a similar problem. I didn't quite understand the second solution that you suggested. How would closing the read side of the pipe in the httpd child processes help in solving this problem ? Thanks, Kiran Arkadi Shishlov wrote: On Tue, Mar 08, 2005 at 01:22:46PM -0500, Jeff Trawick wrote: On Tue, 08 Mar 2005 19:00:05 +0200, Arkadi Shishlov <[EMAIL PROTECTED]> wrote: So is there any progress with the issue or just nobody is interested? me interested? yes me have time right now? no The more investigation work you can do, the better. If you agree with the 'diagnosis' I can try to cook two patches to verify it. 1. Do not kill pipe log process, let it read the pipe till EOF. Or a patch to cronolog to ignore SIGTERM. 2. Close pipe rd side in children. Is it possible to do in clean way via apr*register/whatever? arkadi.
Re: Terminating cgi scripts
Jeff Trawick wrote:
...
The problem occurs both with mod_cgi and mod_cgid. Being a novice, I
have the following questions. It would be really helpful to get your
take on the following :
1. How do I get all the child pids spawned by the cgid daemon and the
httpd child (mod_cgi) so I can kill them when I get a signal ? Is it
okay if I modify apachectl so that I can get all the processes that are
owned by 'www' and still running using the 'ps' command and then kill
them after "httpd -k stop" ?
I wouldn't pursue that unless there is absolutely no practical way to
fix the code. In the worst case, can't the MPM figure out right
before exiting that it is the parent of some active processes, and
continuing to exit will keep them stranded? But I'd suggest pursuing
the mod_cgid issues first.
2. If that is not acceptable, I would need to change the code. I looked
at the mod_cgid sources and I found that the pids of all the processes
that cgid spawns are hashed in the hash table script_hash. If I could
make script_hash a static global variable, I could get the pids in the
signal handler and kill the processes. I have changed the code and it is
working. Would I be breaking something ?
If the cgid daemon is about to exit, it is reasonable for it to wipe
out any processes it has created and which are still active. But do
as little as possible in a signal handler (i.e., avoid adding any
logic there). When the existing signal hander is called, it sets a
flag which causes the mainline logic to exit. You should see mod_cgid
exiting the loop "while (!daemon_should_exit) {", and while still in
that function you have addressibility to the hash table.
Thanks ! I did this and it worked.
3. We use the worker MPM. For mod_cgi, I would need to make changes in
worker.c since there is no daemon here.
It is a bad thing if worker.c has logic specific to CGIs. Also, it is
invalid to use mod_cgi with a threaded MPM on Unix. Maybe it will
seem to work, but bad things can happen under heavy load, with
descriptors getting inherited by the wrong child processes.
I did not know this. Thanks.
In mod_cgi code, I find that
everytime a process is spawned, apr_pool_note_subprocess() is called.
On Unix, mod_cgi should only be used with a non-threaded MPM. And
that non-threaded MPM (prefork) child process will not exit* without
cleaning up the pool that the processes have been associated with.
*if something is stalling and keeping the child process from exiting
in a timely manner, the Apache parent will kill the child process,
such that this cleanup will not be performed.
I still want to know how I can get the process id in worker.c. I should be
able to get it from some pool. But I am not able to figure out how. If you
do know, or if theres some kind of document, that would help me too.
Thanks so much for responding.
- Kiran
Terminating cgi scripts
We had a customer scenario (on HP-UX) recently where cgi scripts that were spawned by mod_cgid continued to run even when httpd was stopped. The ppid of these scripts was automatically 1 when the httpd processes terminated. The customer does not find any reason why these processes need to continue to run especially since the scripts need to be run again when httpd restarts. This does seem like a reasonable demand. The problem occurs both with mod_cgi and mod_cgid. Being a novice, I have the following questions. It would be really helpful to get your take on the following : 1. How do I get all the child pids spawned by the cgid daemon and the httpd child (mod_cgi) so I can kill them when I get a signal ? Is it okay if I modify apachectl so that I can get all the processes that are owned by 'www' and still running using the 'ps' command and then kill them after "httpd -k stop" ? 2. If that is not acceptable, I would need to change the code. I looked at the mod_cgid sources and I found that the pids of all the processes that cgid spawns are hashed in the hash table script_hash. If I could make script_hash a static global variable, I could get the pids in the signal handler and kill the processes. I have changed the code and it is working. Would I be breaking something ? 3. We use the worker MPM. For mod_cgi, I would need to make changes in worker.c since there is no daemon here. In mod_cgi code, I find that everytime a process is spawned, apr_pool_note_subprocess() is called. I should be able to retrieve this pid in worker.c when I get the terminate signal. I have tried several ways to do this, but I haven't been successful. Is it possible to retrieve the pid in worker.c and if so how can I do that ? Thanks and Regards, Kiran
