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
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" |