5

Within my systems /run directory I have a bunch of files that have *.pid extensions and store the process id of running daemons, i.e.

% ls -1 /run/*.pid                    
acpid.pid
crond.pid
dhclient-wlp2s0.pid
irqbalance.pid
lightdm.pid
nginx.pid
rsyslogd.pid

And I have generally noticed this is something many other daemons do and that daemon management scripts in /etc/init.d/* will read in the pid from the last running instance and reuse that on starting a new instance.
Why? why not just start the daemon and give it a new pid?
Are there other programs e.g. rsyslog, that are expecting that daemon to have that identifier and would be confused if a different program was using that pid?

Improve this question
11

For many daemons, only one instance of the daemon should be running on a system at any one time. In this use case, the daemon typically stores its PID in a well known directory (on Linux, currently /run, previously /var/run) to indicate that an instance of the daemon is running.

If you attempt to invoke a second instance of such a daemon, the newly invoked daemon checks for an existing entry (think of it as a lock file) under /run and exits if found.

If the daemon is restarted then the PID of the new instance is written to the file. The new instance gets its own PID, there's no way to launch a process with a given PID.

The PID file is also used to determine what process to kill to stop the daemon.

Improve this answer
2
  • makes sense. when a system reboots, won't the "lock file" be already existing ? wouldn't the /etc/init.d script say hey this pid file exists, there must already be a process with that pid running . or do daemons explicitly "clean up" after themselves by always emptying their "pid" file on system shutdown or if you run /etc/init.d/daemon stop (or similar)? – the_velour_fog May 17 '17 at 3:38
  • 3
    /run is generally a tmpfs, which means that it's not actually stored on disks but in memory. Thus, it automatically gets discarded at shutdown and recreated at start up. – user6075516 May 17 '17 at 6:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.