Re: BUG #7559: syslogger doesn't close stdout and stderr

From: Reinhard Max <reinhard(at)m4x(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7559: syslogger doesn't close stdout and stderr
Date: 2012-09-19 21:05:09
Message-ID: alpine.LNX.2.00.1209192234040.663@albrecht.home.m4x.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


On Wed, 19 Sep 2012 at 12:39, Tom Lane wrote:

> reinhard(at)m4x(dot)de writes:
>> When initially starting up, syslogger keeps stdout and stderr open
>> instead of closing them and reopening them from /dev/null for
>> proper daemonisation.
>
> How exactly could it "close and reopen" them without losing their
> identity?

I am not sure what you mean by "losing their identity", but the code
for what I think is the right thing to do was already there. It opens
/dev/null and then calls dup2() to copy it to FDs 1 and 2.

All my patch does is removing the check for the redirection_done
variable which caused this code to only be executed when the logger
gets restarted from postmaster after it has been killed.

> And what makes /dev/null necessarily the right substitute?

Because it is what virtually all deamons have been doing for the last
3..4 decades?

> I don't think we should change this within Postgres. We removed
> logic associated with daemonization altogether in 9.2

Huh - why that?

> it's the responsibility of the calling script to close any files it
> doesn't want left open.

Sorry, but that's nonsense.

Under Unix it has always been the responsibility of a deamon to
properly deamonize itself, which consists of forking, giving up the
controlling TTY and reopening stdin, stdout and stderr from /dev/null.

If you make it the responsibility of the calling sctipt to do the
/dev/null redirection, PostgreSQL has no chance of reporting any
errors it might run into before its own logging has been set up.

cu
Reinhard

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-09-19 21:15:14 Re: BUG #7557: Transaction sees outdated grants.
Previous Message Kevin Grittner 2012-09-19 18:06:51 Re: BUG #7556: "select not in sub query" plan very poor vs "not exists"