Hi,
from my point of view such a thing is very common either if you have a
heavily loaded web server in combination with certain modules e.g.
fastcgi or so.
i was looking once already for kind of a "start delay" of apache
restart and apache graceful but could not find anything to say that
such a delay is probably as well more fixing the phenomena and not the
real issue
but what i did then is a restart with basicaly stopping apache either
graceful or just with a stop then checking for 443 and 80 listening
processes in a loop for a certain time and as soon all the listen ports
are gone i start up the apache again
this can be obvously extended by killing everything related to your
apache instance after e.g. 5min if required and if you want to have
something for analysing the problem you even can do a coredump of that
particular processes before you kill them or what ever you might want
to check during that time.
i think the main issue is that there are still child processes hanging
around for some time even they got sent a kill signal (what happens
with stop and graceful-stop (in the case of graceful only after a
certain delay if configured with GracefulShutdownTimeout))
Aaron
Am 28.05.2010 11:00, schrieb Raphael Bauduin:
On Thu, May 27, 2010 at 6:00 PM, Scott Gifford
<sgifford@xxxxxxxxxxxxxxxx> wrote:
I don't have an answer for you, but here are a few troubleshooting tips I
have found helpful.
Thx for the tips, I'll keep the list posted if I discover the origin
of the problem.
Raph
If you can make it happen pretty often, you could try doing an
strace/truss/ktrace (I think it's ktrace on BSD) of the process to see what
system calls it's making and exactly which is failing. You could also try
running "netstat -an |grep :443" right before and after you run it to see if
there's anything else listening on port 443.
One possibility is that the SO_REUSEADDR socket option somehow isn't being
set, which would be visible in a trace.
Another possibility may be that a child process is doing something with the
socket that prevents it from being closed. You could look in the logs
between restarts and see if that gives a clue. Maybe there's one script
that is triggering this, for example. If you tried a graceful restart every
minute or less, the log interval might be small enough to give you useful
information.
You could also try systematically disabling things and see if that helps,
starting with any modules that aren't used.
I have had similar problems on earlier versions of Apache but was never able
to figure them out. They would only happen once or twice a year, so I
wasn't able to do much troubleshooting. I know that doesn't help, but maybe
it's nice to know that you're not the only one who has seen problems like
this.
Hope this helps!
-----Scott.
On Thu, May 27, 2010 at 10:17 AM, Jeff Trawick <trawick@xxxxxxxxx> wrote:
On Wed, May 26, 2010 at 9:22 AM, Raphael Bauduin <rblists@xxxxxxxxx>
wrote:
Hi,
With an apache 2.2 running on FreeBSD
which level of Apache? (2.2.9 had a change in this area of processing)
which level of FreeBSD?
, I occasionally get
a problem
with a graceful restart.
Issuing the command apachectl graceful results in these messages in
the error log:
[Wed May 26 14:45:48 2010] [notice] Graceful restart requested, doing
restart
[Wed May 26 14:45:53 2010] [warn] module dav_module is already loaded,
skipping
[Wed May 26 14:45:53 2010] [crit] (22)Invalid argument: make_sock: for
address [::]:443, apr_socket_opt_set: (IPV6_V6ONLY)
(48)Address already in use: make_sock: could not bind to address
0.0.0.0:443
no listening sockets available, shutting down
hmmm... dunno why setting that socket option is failing (the first
[crit] message)
if you don't need IPv6, change your Listen directive from "Listen 443"
to "Listen 0.0.0.0:443" to work around the problem, whatever it is
or this
[Wed May 26 15:02:52 2010] [notice] Graceful restart requested, doing
restart
[Wed May 26 15:02:57 2010] [warn] module dav_module is already loaded,
skipping
(48)Address already in use: make_sock: could not bind to address
[::]:443
This error is not systematic, but it makes the command unreliable and
unusable in a cron task.
Any hint as to what causes this problem?
Thanks in advance!
Raph
--
Web database: http://www.myowndb.com
Free Software Developers Meeting: http://www.fosdem.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--
Born in Roswell... married an alien...
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|
