[Top][All Lists]
[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