|Syntactic Confectionery Delight|
Not in principle. Pid files have their problems (something may throw away the file, the pid may have been reused, race conditions if you don't use locking (but if you use locking, why have a pid file?)), but they are just a file.In discussing whether or not a "pid" (or "lock") file is good or bad, it is useful to define what one should be used for. The point of the lock file is to signal other processes that access to a system resource is controlled (for whatever reason).
Take a simple, single user environment. If I start a program in a window that utilizes several specific data files, and those file should only be updated by my program, the simple way is to implement file locking. That way, if another instance of the program is started, it will fail on file access. Not very pretty (if multiple files are accessed, you have to lock all of them), but effective. A better way is to check for the instance of the lock file - a way of saying "this set of resources is in use". Cleanup is easy. It also allows for graceful recovery when the user mistakenly starts another instance of the program.
Now, extend that to long running processes (daemons or server processes) that require exclusive access to specific system resources (database, web, ftp etc). Such access may be relatively easy to handle (network ports, etc), or relatively expensive (cleanly shutting down a large database server can be time consuming, with failure extremely painful). Under these circumstances, you would need to be able to control the server from an arbitrary location (not necessarily the terminal process from which it was started).
Enter the "pid" file (a file whose existance signals that the service is - or was - running). The content of the file is the process id (hence the name) of the controlling process. The file's (non)existance can communicate the state of the process:
As noted above, the PID file is typically located in /var/run (or /usr/local/var/run). This allows for orderly and generic startup and shutdown procedures, as well as troubleshooting. If you do not have to go searching for pid files, it is much quicker.
The PID file also serves another purpose: it allows external resources to communicate with the service in a specified manner. Take, for instance, the "cron" process, which provides scheduled processes to run. In order to maintain the process, you can either edit the configuration files and restart the process, or you can send it a message to reread it's files. The "standard" unix method for maintaining the configuration is through the "crontab" program. When the configuration is changed (by crontab -e or crontab -r, the program sends a "SIGHUP" signal to the process whose id is contained in the PID file. The cron process does not shut down, but simply rereads it's configuration.
Yes, the use of such files adds some complexity to the program, but in many cases, the added functionality is worth it (at least in my not so humble opinion :-D ). YMMV.
Update: Added explicit reference to pid file location.
In reply to Re^2: Proc::PID::File problem generating pid files, or: does it matter where a pid file lives?