Fwd: Default pg_autovacuum config glitches

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.

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.