Re: [bug-inetutils] On hardcoded pid-files.

[Alfred M. Szmidt]

   > > Personally, I'd like to get the whole PID file cruft removed...  ftpd,
   > > inetd, and what not should return the proper PID via other means.
   > 
   > Uh? What other means? The pid needs to be stored somewhere anyway to
   > be able to control the daemon later on. Shifting to someone else
   > having to create the pid file makes life more difficult for everyone
   > else w/o no apparent reason. pid file creation should be under 20
   > lines of code anyway!

   Closer to a dozen lines at the moment!

And this has to be in all the daemons, and there is no easy way to
make a simple function for this since the argp structure needs to be
updated.  The whole concept of PID files is broken, and it is not
portable.  You also have cases where you might end up with multiple
deamons running, on different ports, in which case you will only store
a single PID in the PID file.

The proper way to get the PID of a process is a simple case of using
$!, pgrep or similar means.

   Personnally I would like to see a mechanism that allows the
   administrator or tester to inhibit the creation of a PID file.
   Could the setting of an empty path be used to achieve this, this
   avoiding the bare use of `-p' and also making the option take a
   mandatatory argument?

You can pass /dev/null as the file.