Mailing List Archive: Suggested improvements to pid

Suggested improvements to pid_file handling

Feb 24, 2005, 1:38 PM

Post #1 of 3 (1367 views)

Nigel tells us:

> The exim-dev@exim.org had an original brief of discussing changes to the
> development process. The initial phase of this has now completed, and
> so the list is changing function to be the primary forum for the
> discussion of exim development - for example this is the place to
> propose and discuss new features, bugs in exim's code or documentation
> etc.

... so, I hope this is now the appropriate place to post the following.

While trying to make robust start/stop scripts for Exim under Solaris
(high time to remove the sendmail packages!) I have become aware of some
deficiencies in Exim's pid_file handling. In particular, it does nothing
to invalidate the file contents when the daemon process terminates.

Although pid_file's have inevitable failure cases, it's possible to do
a great deal better than this. I suggest

(a) Exim should try to unlink the file when the daemon exits: it's
not always the case that it can't do this after it has lost root
privilege;

(b) In case it can't, it should keep the file open, and on exit it
should truncate it to size zero if it can't unlink it.

--
Chris Thompson University of Cambridge Computing Service,
Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.

Re: Suggested improvements to pid_file handling [ In reply to ]

ph10 at cus

Feb 25, 2005, 3:38 AM

Post #2 of 3 (1326 views)

Permalink

On Thu, 24 Feb 2005, Chris Thompson wrote:

> Although pid_file's have inevitable failure cases, it's possible to do
> a great deal better than this. I suggest
>
> (a) Exim should try to unlink the file when the daemon exits: it's
> not always the case that it can't do this after it has lost root
> privilege;
>
> (b) In case it can't, it should keep the file open, and on exit it
> should truncate it to size zero if it can't unlink it.

I think the problem here is "when the daemon exits". I guess it has to
set up a signal handler to catch the KILL signal; I'm just wary about
signal handling because I know what a hairy area of system programming
it is. :-)

The keeping open option may be tricky/difficult after SIGHUP, when Exim
has re-executed itself, but still in the same process.

Would you like me to wishlist this issue?

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

Re: Suggested improvements to pid_file handling [ In reply to ]

cet1 at cus

Feb 25, 2005, 4:49 AM

Post #3 of 3 (1319 views)

Permalink

Philip Hazel writes:
>
> On Thu, 24 Feb 2005, Chris Thompson wrote:
>
> > Although pid_file's have inevitable failure cases, it's possible to do
> > a great deal better than this. I suggest
> >
> > (a) Exim should try to unlink the file when the daemon exits: it's
> > not always the case that it can't do this after it has lost root
> > privilege;
> >
> > (b) In case it can't, it should keep the file open, and on exit it
> > should truncate it to size zero if it can't unlink it.
>
> I think the problem here is "when the daemon exits". I guess it has to
> set up a signal handler to catch the KILL signal; I'm just wary about
> signal handling because I know what a hairy area of system programming
> it is. :-)

Well not KILL, obviously, but I suppose I was assuming a TERM signal handler.

> The keeping open option may be tricky/difficult after SIGHUP, when Exim
> has re-executed itself, but still in the same process.

This should be treated as exiting: the old instance removes/empties the
pid_file, and the new one after exec'ing recreates it. The exec'd copy
doesn't know there was an earlier incarnation in the same process, does it?

I suppose the open pid_file needs to be close-on-exec anyway so that it
isn't inherited by spawn of the daemon with possible security implications.

> Would you like me to wishlist this issue?

Yes: at least a general wish to get the pid_file invalidated somehow.

--
Chris Thompson University of Cambridge Computing Service,
Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.