Apache2 waits indefinetely when reloading

Bug #1463635 reported by Nano.net.tr
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apache2 (Ubuntu)
Expired
Medium
Unassigned

Bug Description

System : Ubuntu 14.04.2 LTS
Package : apache2 - 2.4.7-1ubuntu4.4

Description :
When a reload invoked by logrotate;
2-3 time in a week apache2 stops responding requests in our web server.
While in this period, clients can connect but waits indefinitely for a reply.
Then apache2 needs a full restart to start serve web pages.
Reload does not work in this situation.

After some research we found that Apache2 has a GracefulShutdownTimeout directive that kill remaining requests after a timeout.
But this directive not set (defaults to zero) in default Ubuntu config.
( See : http://httpd.apache.org/docs/2.4/en/mod/mpm_common.html )

This should have a reasonable value in default config.

Expected :
Apache2 reloads and continues to serve web pages without human interaction.

Happened :
Apache2 waits for remaining requests indefinitely and needs a restart.

Nano.net.tr (software-0)
description: updated
Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time for reporting this bug and helping to make Ubuntu better.

With the default GracefulShutdownTimeout, Apache should still shut down after all existing requests have been served, and the reload should still occur. Based on that description, I don't yet see a bug in the default configuration.

Do you know why this isn't happening correctly in your case? Do you have a web application that is hanging on requests indefinitely, or anything like that?

Revision history for this message
Nano.net.tr (software-0) wrote :

We dont exactly know why connection remains open.
There could be a problematic client connected or buggy php script running on the server.

Whatever causes the problem that means if apache waits indefinitely, anybody could launch a DOS attack on server (via a crafted, never ending request).

Also in another view;
If this problem occurs, an inexperienced system administrator could not be solve that.

I think default configurations must be safe, secure, user friendly and tuneable.

If Ubuntu team thinks, thats the job of a system admin then i will respect that and close the report.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
you are right that default configurations should be sane.
I totally like your report on the potential DOS, by keeping a connection open and so stalling the restart forever.
So I don't just want you or me to close it.
But then the GracefulShutdownTimeout being zero is the apache default - not one set by Ubuntu.

I see two issues in "just" changing that:
- while discussion worthy, some other users might expect it to behave as it did up to now
- Upstream must have a reason to keep the default at zero (I hope)

I'd suggest to bring the matter to discussion upstream with Apache.
There the experts can much better quantify the reality of an attack due to this or any other implications.
E.g. the answer to why exactly the connections remain open and what could/should be done.

Once there is agreement and a patch that changes the upstream default new versions will pick it up and it could be back-ported to old versions as needed.

Changed in apache2 (Ubuntu):
status: New → Triaged
importance: Undecided → Low
importance: Low → Medium
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

For the discussion of "safe" defaults the closing of open connections is just as unsafe.
You lost 1M$ because your transaction was lost on this reload.

Really a discussion to be had upstream as I said back then.
I want to mark this accordingly as incomplete as IMHO this isn't actionable by Ubuntu without upstream consensus on a changed default.

Changed in apache2 (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for apache2 (Ubuntu) because there has been no activity for 60 days.]

Changed in apache2 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.