[
https://jira.jboss.org/jira/browse/MODCLUSTER-120?page=com.atlassian.jira...
]
Jean-Frederic Clere commented on MODCLUSTER-120:
------------------------------------------------
After a long analysis it seems that when httpd crahes (or is kill -9) the shared memory is
not cleaned.
When restarting httpd can't attach to it, nor remove it nor create it.
What the work-around is doing:
1 - attach (create a file but ftok() doesn't correspond.
2 - remove that failed because ftok() is not ok but it also remove the file.
3 - create failed because the file it create correspond to a ftok() result of the previous
run. (note that file is not closed APR bug?).
4 - go 2
When doing that loop enough up to 5 times, 2 good things are happening:
a) - remove is successful because ftok() corresponds to an existing shared memory.
b) - create because the new file don't correspond to an exist shared memory... In this
case the shared memory is left unused in the box.
BTW: a) should always takes place if 3 failed with APR_EEXIST but that is not the
case....
Apache with mod_cluster refuses to start at first, after 7 retries it
starts up
-------------------------------------------------------------------------------
Key: MODCLUSTER-120
URL:
https://jira.jboss.org/jira/browse/MODCLUSTER-120
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.0.2.GA
Environment: x64, RHEL 5.2, Server version: Apache/2.2.13 (Unix)
Reporter: Radoslav Husar
Assignee: Jean-Frederic Clere
Priority: Critical
Attachments: MODCLUSTER-120.log
When starting up Apache with mod cluster, by command:
[hudson@perf10 httpd]$ /usr/sbin/apachectl -k start -d /tmp/hudson/httpd
It refuses to start, but creates files in logs one-by-one and then when all files are
created it accepts to start.
[hudson@perf10 httpd]$ cat logs/error_log
[Tue Jan 05 12:01:11 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jan 05 12:01:11 2010] [notice] Digest: generating secret for digest authentication
...
[Tue Jan 05 12:01:11 2010] [notice] Digest: done
[Tue Jan 05 12:01:11 2010] [emerg] create_mem_node /tmp/hudson/httpd/logs/manager.node
failed
Configuration Failed
[Tue Jan 05 12:01:37 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jan 05 12:01:37 2010] [notice] Digest: generating secret for digest authentication
...
[Tue Jan 05 12:01:37 2010] [notice] Digest: done
[Tue Jan 05 12:01:37 2010] [emerg] create_mem_context failed
Configuration Failed
[Tue Jan 05 12:02:40 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jan 05 12:02:40 2010] [notice] Digest: generating secret for digest authentication
...
[Tue Jan 05 12:02:40 2010] [notice] Digest: done
[Tue Jan 05 12:02:40 2010] [emerg] create_mem_host failed
Configuration Failed
[Tue Jan 05 12:04:43 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jan 05 12:04:43 2010] [notice] Digest: generating secret for digest authentication
...
[Tue Jan 05 12:04:43 2010] [notice] Digest: done
[Tue Jan 05 12:04:43 2010] [emerg] create_mem_balancer failed
Configuration Failed
[Tue Jan 05 12:04:44 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jan 05 12:04:44 2010] [notice] Digest: generating secret for digest authentication
...
[Tue Jan 05 12:04:44 2010] [notice] Digest: done
[Tue Jan 05 12:04:44 2010] [emerg] create_mem_sessionid failed
Configuration Failed
[Tue Jan 05 12:04:45 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jan 05 12:04:45 2010] [notice] Digest: generating secret for digest authentication
...
[Tue Jan 05 12:04:45 2010] [notice] Digest: done
[Tue Jan 05 12:04:45 2010] [emerg] create_mem_domain failed
Configuration Failed
[Tue Jan 05 12:04:46 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jan 05 12:04:46 2010] [notice] Digest: generating secret for digest authentication
...
[Tue Jan 05 12:04:46 2010] [notice] Digest: done
[Tue Jan 05 12:04:46 2010] [notice] Advertise initialized for process 1713
[Tue Jan 05 12:04:46 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal
operations
The configuration is here:
https://svn.devel.redhat.com/repos/jboss-qa/load-testing/etc/httpd/mod_cl...
Is there a workaround? What might be causing this?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira