/etc/init.d/apache2 greps excessively for PidFile

Bug #112991 reported by Malcolm Scott
10
Affects Status Importance Assigned to Milestone
apache2 (Debian)
Fix Released
Unknown
apache2 (Ubuntu)
Fix Released
Medium
Ubuntu Server

Bug Description

Binary package hint: apache2

/etc/init.d/apache2 does a "grep ^PidFile /etc/apache2/* -r". It is not uncommon for there to exist a symlink from /etc/apache2/logs to /var/log/apache2: this causes that invocation of grep to scan through all of Apache's log files. On my web server there are several gigabytes of these, causing "/etc/init.d/apache2 stop" during shutdown to take a very long time.

I suggest not following symlinks, for starters, using something like this instead perhaps:

find /etc/apache2/ -type f -print0 | xargs -0 grep ^PidFile

Or ideally being more intelligent about which files to look at, e.g. *.conf...

Tags: patch
Revision history for this message
Malcolm Scott (malcscott) wrote :

Sorry, should have mentioned: I'm using feisty.

Revision history for this message
Caspar Clemens Mierau (leitmedium) wrote :

Though I don't agree that the possibility of having a symlink to logs in /etc/apache2 urges to change something (etc is configuration, not a place for logging), this grep has two main (other) disadvantages:

1. It reads an unkown number of files without reason (remember: a dedicated host might have hundreds of files and symlinks in sites-enabled|sites-available.
2. It would even parse a file like apache.conf.backup and check if there is a pid to kill.

Therefore I'd only parse .conf files or better apache2.conf as this is the place to configure the location of the PidFile. Besides this would solve the mentioned problem.

Maybe this should be filed upstream.

Changed in apache2:
assignee: nobody → ubuntu-server
status: New → Confirmed
Daniel Hahler (blueyed)
Changed in apache2:
importance: Undecided → Medium
Revision history for this message
Daniel Hahler (blueyed) wrote :
Changed in apache2:
status: Confirmed → Triaged
Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :

There is a new version of apache on hardy.

Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :

Uploading debdiff of the change applied to the new version, merging it with Bug #130836 (https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/130836)

Revision history for this message
Daniel Holbach (dholbach) wrote :

Can somebody of the Server Team take a look at it?

Revision history for this message
Scott Kitterman (kitterman) wrote : Re: [Bug 112991] Re: /etc/init.d/apache2 greps excessively for PidFile

IIRC it's covered in a debdiff sorensaid he'd look at after alpha 3 was
out.

Changed in apache2:
status: Unknown → New
Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :

Yep, soren said he will upload it after the next alpha release, but this change: https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/130836 he hasn't say anything abut this bug. mathiaz also told me he's unsure about this grep, so we need to keep looking for a better/alternative solution

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apache2 - 2.2.6-3ubuntu2

---------------
apache2 (2.2.6-3ubuntu2) hardy; urgency=low

  [ Nicolas Valcárcel ]
  * Added icons for OpenDocuments by default on mime.conf
    (Closes: LP: #130836)
  * Icons added to the package in uuencode format
  * Added sharutils to Build-Depends on debian/control for uuencode
  * debian/apache2.2-common.apache2.init:
    - Only look for *.conf files in /etc/apache2 when searching for pidfiles
      (Closes: LP: #112991) Thanks to Daniel Hahler for the patch

  [ Soren Hansen ]
  * Clean up after OpenDocument icon generation

 -- Soren Hansen <email address hidden> Wed, 16 Jan 2008 08:52:01 +0100

Changed in apache2:
status: Triaged → Fix Released
Changed in apache2:
status: New → Fix Committed
Changed in apache2:
status: Fix Committed → Fix Released
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.