Bug 505002 - httpd init script does not work when PidFile option is not set in httpd.conf
Summary: httpd init script does not work when PidFile option is not set in httpd.conf
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: httpd
Version: 5.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Joe Orton
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks: 512221 547629
TreeView+ depends on / blocked
 
Reported: 2009-06-10 10:39 UTC by Olivier Fourdan
Modified: 2018-10-27 15:02 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 512221 547629 (view as bug list)
Environment:
Last Closed: 2010-03-30 08:28:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Additional patch to document the use of PIDFILE (1.55 KB, patch)
2009-06-22 09:25 UTC, Olivier Fourdan
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2010:0252 0 normal SHIPPED_LIVE httpd bug fix and enhancement update 2012-05-17 17:57:35 UTC

Description Olivier Fourdan 2009-06-10 10:39:17 UTC
Description of problem:

The init script for httpd relies on the presence of the pid file for stop, reload and condrestart.

However, the pid file location can be changed in httpd.conf or even not specified at all which would break the script.

The location of the pid file can be specified by setting PIDFILE in "/etc/sysconfig/httpd", but that will not work if no PidFile option is set in httpd.conf (ie no pidfile at all)

Version-Release number of selected component (if applicable):

httpd-2.2.3-22.el5_3.1

How reproducible:

100% reproducible

Steps to Reproduce:

1. Stop Apache
   # service httpd stop
   Stopping httpd:                                            [  OK  ]

2. Comment out PidFile in /etc/httpd/conf/httpd.conf
   # PidFile run/httpd.pid
   
3. Start Apache
   # service httpd start
   Starting httpd:                                            [  OK  ]

4. Use condrestart
   # service httpd condrestart
   => Nothing happens

Actual results:

  Nothing, Apache is not restarted

Expected result:

  Stopping httpd:                                            [  OK  ]
  Starting httpd:                                            [  OK  ]
      
Additional info:

The fix for bug #491135 makes the matter actually worse:

1. Upgrade to httpd-2.2.3-27.el5 which includes the fix for bug #491135

2. Start Apache
   # service httpd start
   Starting httpd:                                            [  OK  ]

3. Check if it's running:
   # service httpd status
   httpd dead but subsys locked

4. Use condrestart
   # service httpd condrestart
   => Nothing happens

5. Stop Apache
   # service httpd stop
   Stopping httpd:                                            [FAILED]
   
6. Start Apache again:
   service httpd start
   Starting httpd: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
   no listening sockets available, shutting down
   Unable to open logs
                                                           [FAILED]


Our customer suggests using lockfile instead of pidfile, by testing for the existence of the lockfile in stop, reload and in condrestart as follow. Yet, if the script cannot find the pidfile (PidFile not specified in httpd.conf) then stop will not work with the patch from bug #491135.
  
  stop() {
        [ -f ${lockfile} ] || return;
        echo -n $"Stopping $prog: "
        killproc -d 10 $httpd
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && rm -f ${lockfile} ${pidfile}
  }
  reload() {
        [ -f ${lockfile} ] || return;
        echo -n $"Reloading $prog: "
        if ! LANG=$HTTPD_LANG $httpd $OPTIONS -t >&/dev/null; then
         RETVAL=$?
        echo $"not reloading due to configuration syntax error"
        failure $"not reloading $httpd due to configuration syntax error"
    else
        killproc $httpd -HUP
        RETVAL=$?
    fi
    echo
  ...

  # See how we were called.
  case "$1" in
  ...
  condrestart)
        if [ -f ${lockfile} ] ; then
                stop
                start
        fi
        ;;
  ...
  
So I do not think that would fix the problem with the init script stopping other httpd processes since it's not using the pidfile, which is the only way to identify reliably the pid of the httpd started by the script.

When no PidFile is specified in the httpd.conf, Apache will use the default hardcoded value which is in logs/

 #define DEFAULT_PIDLOG DEFAULT_REL_RUNTIMEDIR "/httpd.pid"
 
with 
 
 #define DEFAULT_REL_RUNTIMEDIR "logs"

Thus, if no PidFile is specified, the httpd.pid will be created in "/var/log/httpd/httpd.pid" by default while the init script looks for it in "/var/run/httpd.pid", causing the breakage.

One possibility could be to specify the default location of httpd.pid at compile time by setting DEFAULT_PIDLOG to /var/run/httpd.pid, in the spec file:

  CFLAGS="$RPM_OPT_FLAGS -DDEFAULT_PIDLOG=\\\"/var/run/httpd.pid\\\" -fno-strict-aliasing"
  
In that case it seems to work without a PidFile specified in httpd.conf:

  # service httpd status
  httpd is stopped
  # service httpd start
  Starting httpd:                                            [  OK  ]
  # service httpd status
  httpd (pid  19925) is running...
  # service httpd condrestart
  Stopping httpd:                                            [  OK  ]
  Starting httpd:                                            [  OK  ]
  # service httpd stop
  Stopping httpd:                                            [  OK  ]

And also when an alternate location is specified in both httpd.conf and in "/etc/sysconfig/httpd":

  $ grep -i pidfile /etc/sysconfig/httpd
  PIDFILE=/tmp/httpd.pid
  
  $ grep -i pidfile /etc/httpd/conf/httpd.conf
  PidFile /tmp/httpd.pid

  # service httpd status
  httpd is stopped
  #  service httpd start
  Starting httpd:                                            [  OK  ]
  # service httpd status
  httpd (pid  21372) is running...
  #  service httpd condrestart
  Stopping httpd:                                            [  OK  ]
  Starting httpd:                                            [  OK  ]
  # service httpd stop
  Stopping httpd:                                            [  OK  ]

So setting DEFAULT_PIDLOG to the correct location in the spec file seems to be an appropriate fix.

Comment 1 Olivier Fourdan 2009-06-22 09:25:15 UTC
Created attachment 348870 [details]
Additional patch to document the use of PIDFILE

This patch adds comments in httpd.conf, httpd init script and sysconf script to document the use of PIDFILE to specify an alternate location for the PID file.

This patch does not replace the fix documented in the description, it's a complement to the fix.

Comment 3 Joe Orton 2009-08-20 08:56:49 UTC
I agree that changing DEFAULT_PIDLOG is correct, per our off-line conversation.

I am reluctant to change the httpd.conf or sysconfig file in a RHEL5 update merely to add documentation, as it causes confusion on updates (.rpmsave files, etc), but I will do so for the next major release.  Changing the init file is no problem either.

Comment 7 Chris Ward 2010-02-11 10:33:29 UTC
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~

RHEL 5.5 Beta has been released! There should be a fix present in this 
release that addresses your request. Please test and report back results 
here, by March 3rd 2010 (2010-03-03) or sooner.

Upon successful verification of this request, post your results and update 
the Verified field in Bugzilla with the appropriate value.

If you encounter any issues while testing, please describe them and set 
this bug into NEED_INFO. If you encounter new defects or have additional 
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.

Comment 12 errata-xmlrpc 2010-03-30 08:28:11 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0252.html


Note You need to log in before you can comment on or make changes to this bug.