2

I'm reading documentation on supervisor, and it quotes:

It’s often difficult to get accurate up/down status on processes on UNIX. Pidfiles often lie. Supervisord starts processes as subprocesses, so it always knows the true up/down status of its children and can be queried conveniently for this data.

  1. Couldn't the status of a process be retrieved simply by ps? (or is the problem here that the user querying the status of process shouldn't necessarily have full access to ps)
  2. What are the problems with pid files (eg: do services often leave the pid file behind when they crash)?

2 Answers 2

1
  1. There are only a finite number of PIDs available, so it's possible (although unlikely) for your process to exit and then for some completely different process to start up with the same PID. To be sure you were looking at the right process with ps you'd have to check the start time too, but who bothers with that?
  2. The pidfile is typically managed by an rc script, not the process itself, and as you suspect, it's possible for them to be left behind when a process or server crashes. It then has to be decided somehow that the pidfile is safe to be removed, perhaps by using ps to look for a process with that PID. But, see item 1.
1

Yes you could use ps. But often programs that provide services run in background and/or started at boot time, so for convienience a shell script that starts them records their pid in a runfile.

It has been known for stray pidfiles to be left around after a program dies, so relying on the pidfile alone can be flakey.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .