httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: svn commit: r910705 - in /httpd/httpd/trunk: CHANGES docs/manual/programs/htcacheclean.xml support/htcacheclean.c
Date Thu, 18 Feb 2010 13:56:01 GMT
On Wed, Feb 17, 2010 at 7:56 PM, Graham Leggett <> wrote:
> On 17 Feb 2010, at 8:54 PM, Jeff Trawick wrote:
>> The daemon-report-pidfile-error situation seems to be easily handled
>> just by reversing the order of the apr_proc_detach block with the
>> if-pidfile block.  Then the unusable pidfile path error could be
>> reported to the console in conjunction with -d just like a bogus cache
>> path or such errors (which are already fatal).
> In the process you end up logging the pid of the parent process, the process
> doomed to exit on daemonisation, and not the child process, which is the pid
> you want to keep track of.

whoops :(

> One option is to open the file before the daemonisation, and write the pid
> file after the daemonisation, assuming this kind of thing is portable, I
> don't know.

simply logging it twice in the case of daemonization should avoid any
odd behavior as well as allow reporting almost all error scenarios to
the console; that also requires closing the open pidfile handle before
daemonizing to avoid a race between unlink in the parent and creation
in the child; the attached patch seems to work

I still think exit() is in order after failing to write the pidfile,
even when there's nowhere to report an error logging the pid.  There
are pros and cons, but in the interest of scripts that monitor or
terminate the daemon it seems best that no pidfile means no active

View raw message