Conrad Lender <crlender@gmail.com> writes:
> I looked into the startup scripts that are used here (Ubuntu 8.10):
> ...
> The pg_ctlcluster script parses postgresql.conf and, if log_filename and
> log_directory aren't defined there, adds '-l
> /var/log/postgresql/postgresql-8.3-main.log' as an option for pg_ctl.
> This file is created with the appropriate permissions if necessary.
> The script then forks, and the child detaches itself from the terminal
> and redirects stdout and stderr to /dev/null:
> setsid;
> dup2(POSIX::open('/dev/null', POSIX::O_WRONLY), 1);
> dup2(POSIX::open('/dev/null', POSIX::O_WRONLY), 2);
> exec $pg_ctl @options;
This seems like a whole lot of work to do mostly the wrong thing.
I think the Ubuntu maintainer has failed to think carefully about
what should happen to startup-time messages --- what if pg_ctl itself
fails and would like to say something about that? Good luck finding
out about that from /dev/null. What about postmaster messages that are
emitted before the postgresql.conf logging options have taken effect?
If there are any such options, early messages will end up in /dev/null
too because the -l switch isn't supplied.
It's a lot simpler and safer to just unconditionally send stderr to
someplace reliable throughout the startup process. Now you don't
really want that once the postmaster is up and running, because there's
no provision for log rotation on plain stderr output --- but that's
what the postgresql.conf logging options are for. But trying to be
fancy about what happens before they've kicked in isn't very productive,
and in this case seems downright counterproductive.
regards, tom lane
