Thread: Fwd: Default pg_autovacuum config glitches
Hi PostgreSQL hackers!
A while ago we received the bug report below against pg_autovacuum.
Since it runs as a daemon, it should detach from its controlling
terminal by executing sth like
int nullfd =3D open("/dev/null", O_RDWR);
dup2(nullfd, 0);
dup2(nullfd, 1);
dup2(nullfd, 2);
if (nullfd !=3D 0 && nullfd !=3D 1 && nullfd !=3D 2)
close(nullfd);
(taken from syslog-ng which does it properly).
Can you do that in the next release?
Thanks in advance and have a nice day!
Martin
----- Forwarded message from sacrificial-spam-address@horizon.com -----
Date: 31 Dec 2003 15:02:22 -0000
From: sacrificial-spam-address@horizon.com
To: submit@bugs.debian.org
Subject: Default pg_autovacuum config glitches
X-Spam-Status: No, hits=3D-3.8 required=3D4.0 tests=3DHAS_PACKAGE,NO_REAL_N=
AME=20
autolearn=3Dno=20
version=3D2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_12_29
Package: postgresql
Version: 7.4.1-1
When /etc/init.d/postgresql is run, pg_autovacuum maintains connections
to the startup tty on fds 0, 1 and 2. When run from the console (as part
of (apt-get upgrade), this caused some hiccups to a following getty.
In any case, it's considered bad behaviour on the part of a long-running
daemon.
(If you feel this is pg_autovacuum's fault rather than the init script's,
please reassign to postgresql-contrib.)
Thanks!
----- End forwarded message -----
--=20
Martin Pitt Debian GNU/Linux Developer
martin@piware.de mpitt@debian.org
http://www.piware.de http://www.debian.org
On Thu, Mar 25, 2004 at 16:08:49 +0100,
Martin Pitt <martin@piware.de> wrote:
> Hi PostgreSQL hackers!
>
> A while ago we received the bug report below against pg_autovacuum.
> Since it runs as a daemon, it should detach from its controlling
> terminal by executing sth like
>
> int nullfd = open("/dev/null", O_RDWR);
> dup2(nullfd, 0);
> dup2(nullfd, 1);
> dup2(nullfd, 2);
> if (nullfd != 0 && nullfd != 1 && nullfd != 2)
> close(nullfd);
>
> (taken from syslog-ng which does it properly).
That doesn't look like a good idea. This will prevent any logging to
stdout or stderr.
If you don't want that ability you can redirect the stdin, stdout and
stderr yourself.
>
> Can you do that in the next release?
>
> Thanks in advance and have a nice day!
>
> Martin
>
> ----- Forwarded message from sacrificial-spam-address@horizon.com -----
>
> Date: 31 Dec 2003 15:02:22 -0000
> From: sacrificial-spam-address@horizon.com
> To: submit@bugs.debian.org
> Subject: Default pg_autovacuum config glitches
> X-Spam-Status: No, hits=-3.8 required=4.0 tests=HAS_PACKAGE,NO_REAL_NAME
> autolearn=no
> version=2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_12_29
>
> Package: postgresql
> Version: 7.4.1-1
>
> When /etc/init.d/postgresql is run, pg_autovacuum maintains connections
> to the startup tty on fds 0, 1 and 2. When run from the console (as part
> of (apt-get upgrade), this caused some hiccups to a following getty.
>
> In any case, it's considered bad behaviour on the part of a long-running
> daemon.
>
> (If you feel this is pg_autovacuum's fault rather than the init script's,
> please reassign to postgresql-contrib.)
>
> Thanks!
>
> ----- End forwarded message -----
>
> --
> Martin Pitt Debian GNU/Linux Developer
> martin@piware.de mpitt@debian.org
> http://www.piware.de http://www.debian.org
Bruno Wolff III wrote:
>On Thu, Mar 25, 2004 at 16:08:49 +0100,
> Martin Pitt <martin@piware.de> wrote:
>
>
>>A while ago we received the bug report below against pg_autovacuum.
>>Since it runs as a daemon, it should detach from its controlling
>>terminal by executing sth like
>>
>> int nullfd = open("/dev/null", O_RDWR);
>> dup2(nullfd, 0);
>> dup2(nullfd, 1);
>> dup2(nullfd, 2);
>> if (nullfd != 0 && nullfd != 1 && nullfd != 2)
>> close(nullfd);
>>
>>(taken from syslog-ng which does it properly).
>>
>>
>
>That doesn't look like a good idea. This will prevent any logging to
>stdout or stderr.
>
>If you don't want that ability you can redirect the stdin, stdout and
>stderr yourself.
>
I have stayed quiet about this since I wanted to hear what others
thought of the above suggest fix. I took the detach code straight from
the postmaster daemonize function. Perhaps I didn't do something right
but that was the example I followed. Thoughts? Anyone else had this
problem?
BTW, I think this will be moon in 7.5 since it looks like pg_autovaccum
will be launched by the postmaster.
Matthew
On Sat, Mar 27, 2004 at 00:56:47 +0100, Martin Pitt <martin@piware.de> wrote: > > Well, daemons that run for a long time should not log to > stdout/stderr, but to syslog. Otherwise they clutter up the screen > randomly or the messages are not seen at all (when you are only > working under X for example). pg_autovacuum already does that > (/var/log/postgresql/autovacuum_log in Debian), so I don't see any > reason why it should not log errors there, too. Some people don't want to use syslog for logging for various reasons. Logging to stdout is very attractive because your can pipe the output to your favorite logging program. > > If you don't want that ability you can redirect the stdin, stdout and > > stderr yourself. > > I already thought about that, but if there's a startup problem with > autovacumm then I would not see this as well, but I want that. An > ideal daemon attempts to start and either writes an error to stderr > why it cannot start, or detaches from its terminal when it started > successfully. I think you will find that there are a number people that will disaggree with you about this. Why would the program write some errors only to stdout (or stderr) and others to syslog? If the program were to always write errors to syslog (and maybe copy them to stderr) you would find the error messages in the logs even if the program was not able to fully start up. > If pg_autovacuum logged everything to syslog, then immediate > redirection would be possible (but not my favourite solution). I am not sure what kind of logging the autovacuum deamon currently does. I currently pipe the output from the postmaster to multilog to do my logging and don't use syslog. I am not currently using the autovacuum daemon so do not have examples of what it logs. However, I probably will use it in the future and don't want it to be only usable with syslog.
On Fri, 26 Mar 2004, Matthew T. O'Connor wrote:
> Bruno Wolff III wrote:
>
> >On Thu, Mar 25, 2004 at 16:08:49 +0100,
> > Martin Pitt <martin@piware.de> wrote:
> >
> >
> >>A while ago we received the bug report below against pg_autovacuum.
> >>Since it runs as a daemon, it should detach from its controlling
> >>terminal by executing sth like
> >>
> >> int nullfd = open("/dev/null", O_RDWR);
> >> dup2(nullfd, 0);
> >> dup2(nullfd, 1);
> >> dup2(nullfd, 2);
> >> if (nullfd != 0 && nullfd != 1 && nullfd != 2)
> >> close(nullfd);
> >>
> >>(taken from syslog-ng which does it properly).
> >>
> >>
> >
> >That doesn't look like a good idea. This will prevent any logging to
> >stdout or stderr.
> >
> >If you don't want that ability you can redirect the stdin, stdout and
> >stderr yourself.
> >
>
> I have stayed quiet about this since I wanted to hear what others
> thought of the above suggest fix. I took the detach code straight from
> the postmaster daemonize function. Perhaps I didn't do something right
The postmaster's seems to have a section that does a null device open,
dup2s and a close at the end of pmdaemonize in the 7.4 and 7.5 versions on
my box:
i = open(NULL_DEV, O_RDWR | PG_BINARY);
dup2(i, 0);
dup2(i, 1);
dup2(i, 2);
close(i);
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> The postmaster's seems to have a section that does a null device open,
> dup2s and a close at the end of pmdaemonize in the 7.4 and 7.5 versions on
> my box:
Yes, and that behavior is exactly why we deprecate -S ... I don't think
that the autovacuum daemon should emulate it.
This is all moot though since we seem to have a consensus that the
autovac daemon will become a postmaster child in 7.5. There is
therefore no reason for it to worry about daemonizing itself.
regards, tom lane
On Sat, 27 Mar 2004, Tom Lane wrote: > Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > > The postmaster's seems to have a section that does a null device open, > > dup2s and a close at the end of pmdaemonize in the 7.4 and 7.5 versions on > > my box: > > Yes, and that behavior is exactly why we deprecate -S ... I don't think > that the autovacuum daemon should emulate it. Oh, I totally agree with that, but wanted to point it out since there seemed to be a question in terms of what the postmaster did in the code that was cribbed for the autovacuum daemon. > This is all moot though since we seem to have a consensus that the > autovac daemon will become a postmaster child in 7.5. There is > therefore no reason for it to worry about daemonizing itself. True, but I sort of inferred that the debian bug was also aimed towards later 7.4 releases.