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

[Bug 62838] semaphores appear to be leaking


--- Comment #6 from William A. Rowe Jr. <wrowe@xxxxxxxxxx> ---
Hi Mark,

You failed to mention your operating system but let's presume this is linux.
Semaphores are not HTTPD's default signaling mechanism, but many third party
modules default to semaphores.

You could narrow down which modules in a non-production environment by
simply checking `ipcs -s` and then avoiding loading one specific module
or another and rechecking. Again, if this is linux, these aren't likely 
from httpd, but from one or more of these non-core third party modules;

 auth_kerb_module (shared)
 suexec_module (shared)
 gateform_module (shared)
 qos_module (shared)
 jk_module (shared)
 weblogic_module (shared)
 ct_auth_module (shared)
 security2_module (shared)

Very often these are httpd-2.2 module legacies which weren't entirely
ported to the capabilities of httpd-2.4. That doesn't mean they won't
work, but modules relying on semaphore locking are subject to the
instability you've described.

>From your logs;

[Thu Oct 18 23:49:37.873019 2018] [core:error] [pid 2050766:tid
140626123683584] AH00046: child process 2064824 still did not exit, sending a

Semaphores orphaned

[Thu Oct 18 23:49:37.873288 2018] [core:error] [pid 2050766:tid
140626123683584] AH00046: child process 2065149 still did not exit, sending a

Semaphores orphaned

Due to the nature of semaphores, there is nothing we can do here. Using
a clever combination of ipcs -s and -p flags it is possible to identify the
semaphores not-in-use, and purge them periodically. An internet search will
quickly lead you to such scripts.

If any of the modules mentioned above are using semaphores, your best next
step is to inquire of those third party module authors and find out whether
there is an updated module available or whether the authors would modify
their module to use the default, preferred apr locking mechanism.

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