Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 5 down vote favorite
2

Many programs such as sshd create .pid files in /var/run/ that contain their process ID. Are these files reliable for determining whether a process is running? My guess is that these files are created manually by a process, and therefore will still remain in the file system if the program crashes.

share|improve this question

migrated from stackoverflow.com Feb 23 '10 at 16:04

4 Answers

up vote 9 down vote accepted

in simple terms, no: a process (e.g. a daemon) can crash and not have the time to clear its .pid file.

A technique to be more certain of the state of a program: use an explicit communication channel such as a socket. Write the socket port in a file and have the supervisor process look it up.

You can also use the services of DBus on Linux: register a specific name and have your supervisor process (whatever you call it) check for that name.

There are numerous techniques.

One thing to remember: it is not the OS' responsibility to manage the PID files.

share|improve this answer
1  
The existence of the pid file, COMBINED with the existence of the process however, should be sufficient. If the process quit, you can check that. PIDs do get reused, but not very often. – MarkR Feb 22 '10 at 21:47
2  
how often a pid gets reused depends upon the particular system in question. I've seen a system were PIDs cycled at least daily. You have to check the pid, that there's a process, and that the process appears to be the one you expect to own the pid. – atk Feb 22 '10 at 21:59
@atk: exactly. There isn't a standard per-se and even if there was one, it can very well be not respected by some implementations. E.g. I can craft a daemon that doesn't write a PID file at all and use a back channel to get its management commands from. – jldupont Feb 22 '10 at 22:05
up vote 2 down vote

Jldupont is correct in stating that .pid files are not reliable for determining whether a process is running as the file may not be removed in the event of a crash.

Race conditions aside, I often use pgrep when I need to know if a process is running. I could then cross-reference the output against the .pid file(s) if I felt it necessary.

share|improve this answer
up vote 1 down vote

Jldupont is correct.

You can, however, send the process a 0 signal (kill -s 0 pid) to see if the process is still alive (assuming you have the authority to send such a signal -- in general, only the owner of a process may send it a signal).

share|improve this answer
3  
But checking for the existence of a process with that PID doesn't mean that it's the PID you're interested it. – janm Feb 23 '10 at 0:37
up vote 0 down vote

I agree with jschmier.

On some systems, you do not get access to pgrep. In such a case, you can do ps -aef | grep <pid> to find out if the process is really running.

share|improve this answer
1  
The key point in the question was "reliable". Doing a ps and looking for a PID is not reliable. – janm Feb 23 '10 at 0:38
well... assuming that you know that name of the program, why do you think ps -aef | grep is unreliable? – user29584 Feb 23 '10 at 1:13
1  
Race conditions: the state of the system has changed by the time ps has finished. Process titles: another process could have a similar title to the one you're interested in. Multiple instances: Consider a system with two instances of the same service, each with a PID file. One fails, and the other restarts and gets the PID of the first service. How do you tell? Etc. Not reliable, impossible to get right because of race conditions, and there are reliable techniques that just work. For a reliable alternative see, for example, cr.yp.to/daemontools.html – janm Feb 23 '10 at 1:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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