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

[Guillem Jover]

On Thu, 2010-11-18 at 12:25:49 -0500, Alfred M. Szmidt wrote:
>    > > 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.

There's lots of small and similar snippets of code that are used in
most programs, still those are needed regardless. In this case what
can be refactored is the action of writting down the pid file. The
argument name might change per daemon anyway.

> The whole concept of PID files is broken, and it is not portable.

I disagree with this, and I don't see how it's not portable. What's
needed to write a pid file is provided by any Unix system. In fact any
other solution is going to be less portable than this.

> 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.

I'd argue in that case you'd need different configuration files and
thus those should be considered different instances and as such have
different pid files.

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

Not really. The proper way to daemonize implies two forks to detach
from the parent and start a new session, which makes the parent unable
to get the pid from the grandchild. It also implies redirecting stdio
to /dev/null.

Also something like pgrep will not work, as there's no way to
distinguish the same daemon running on different chroots (well in a
clean and portable way at least), or simply different instances for
example.

regards,
guillem