Description of Problem:
The pidofproc function in /etc/rc.d/init.d/functions does not return the
proper PID for a process if the /var/run/WHATEVER.pid file is out of sync
with the actual PID of the running program. pidofproc will return the
contents of the /var/run/WHATEVER.pid after simply checking that the
process exists and not checking that the program running at the PID is the
same as the one that is supposed to be running.
The /var/run/WHATEVER.pid file can become out of sync if there is an
improper shutdown (i.e. power loss due to faulty UPS or whatever). Many
scripts in /etc/rc.d/init.d depend on the daemon function which
consequently depends on the pidofproc function to see if the process is
allready running. If for some reason the machine was improperly rebooted
and some other software is running under the PID described for the pid
file for the init funtion, the program won't be started up.
I've attached a patch that uses pidof (as used towards the end of the
function) to attempt to grab the running PID so that a match can be made
between the PID of the running program and the PID stored in the file. The
patch could probably be written better, but I'm not exactly sure how I'd
check reliably for certain processes. pidof seems to work well enough.
Version-Release number of selected component (if applicable):
6.40-1 (but could be any version that has this code)
I've seen it at least a number of times right after our crappy UPS's
started flaking out. The overall problem is not dependably reproduced as
it relies on the chance that the PID's will be shifted into the right
place on the next boot. The vulnerability of pidofproc itself is
dependably reproduced as follows.
Steps to Reproduce:
1. Manually kill a process that is normally run from /etc/rc.d/init.d
(such as sendmail).
2. Find the process ID of some other process running on the system (such
as crond or ntpd).
3. Create a pid file in /var/run for the process you killed in step 1 (for
example /var/run/sendmail.pid for sendmail)
4. Enter the process ID from step 2 into the file from step 3.
5. Attempt to start the program you killed in step 1 via it's script
in /etc/rc.d/init.d (for example "/etc/rc.d/init.d/sendmail start" for
The init script will not start the program/deamon because it sees a
running process matching the process describe in the /var/run PID file.
The init script should start the program/deamon since the actual program
is not running.
This could open a hole for some serious attacks. If for some reason some
firewall software doesn't come up, or some other security software doesn't
come up on reboot because the system "THINKS" the program is allready
running due to a faulty PID file, then protected resources could go
There is also a high chance of annoyance from lack of ability to
authenticate against mysql servers, or third party radius servers, etc.
Also, a system may be rendered unable to allow remote connections due to
lack of xinetd.
Unfortunately there's no real way to tell what isn't going to start on any
particular system after a catastrophic failure. The only way to make sure
everything is running as it should is to either re-boot all machines or
check manually to make sure that everything is running.
Why is it that we blindly depend on that /var/run PID file anyways? pidof
seems to do a much better job, and the data is much less likely to be
Created attachment 40688 [details]
patch to /etc/rc.d/init.d/functions to fix pidofproc
Closing bugs on older, no longer supported, releases. Apologies for any lack of
If this persists on a current release, such as Fedora Core 4, please open a new bug.