[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 48769] [PATCH] Processes in the busy list should not be killed during graceful restarts


Robert Mathews <rob-apachebugs@xxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
             Status|NEEDINFO                    |NEW

--- Comment #10 from Robert Mathews <rob-apachebugs@xxxxxxxxxxxxx> ---
I have been using the attachment 34001 patch in comment #8 successfully on
around a dozen web servers that use "apache2ctl graceful" reloads at least

It fixes the problem described in the bug: Apache can now reload without
interrupting in-flight FCGI requests, and it no longer tries to kill processes
in the free list. This is a huge improvement.

That said, I discovered a slight problem with how the patch works: on each
graceful reload, it "leaks" a shared memory segment and two semaphore arrays,
according to "ipcs". This is apparently because it doesn't clean up the
resources the previous generation created with fcgid_mutex_create(), etc., even
after the graceful reload is finished.

If you reload a large number of times without a restart, this can cause
problems. This can be demonstrated by running this when using the patch:

while `sleep 5`; do echo -n "Reloading: "; ipcs | wc; systemctl reload apache2;

The "ipcs" output will increase by 3 lines for each reload, and if you let this
run for long enough, you will eventually run out of resources, resulting in
something like this:

 Reloading:     186    1019   11366
 Reloading:     189    1036   11556
 Reloading:     192    1053   11746
 Reloading:     195    1070   11936
 Reloading:      18      72     776
 Job for apache2.service failed. See 'systemctl status apache2.service' and
'journalctl -xn' for details.

The error log shows "[core:emerg] [pid 5753] (28)No space left on device:
AH00023: Couldn't create the mpm-accept mutex".

A "systemctl restart apache2" frees up the resources, but it would be better if
this did not happen.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail: bugs-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: bugs-help@xxxxxxxxxxxxxxxx