bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mats Erik Andersson
Subject: Re: [bug-inetutils] On hardcoded pid-files.
Date: Thu, 18 Nov 2010 10:11:52 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

torsdag den 18 november 2010 klockan 05:26 skrev Guillem Jover detta:
> On Fri, 2010-11-05 at 12:45:27 -0400, 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!

I have a change in my testing queue regarding this. It works for
OpenBSD and GNU/Linux, and is as follows:

    * A command line switch `-p' or `--pidfile' activates
      the use of a PID registering file, and in fact uses
      the hard coded path registered at compile time.

    * The expanded forms

            inetd -p/path/to/file
            inetd --pidfile=/path/to/file

      activates the mechanism and replaces the built-in path.

Would it be a serious blow on expected use, to drop the record
keeping of process identity without an explicit `-p' option?

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?


Best regards,
Mats



reply via email to

[Prev in Thread] Current Thread [Next in Thread]