From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050524 Firefox/1.0 (Ubuntu package 1.0.2 MFSA2005-44) Description of problem: Migrating a database from a RHEL3 server to RHEL4; the previous postgresql.conf file had the options: max_fsm_relations = 10000 max_fsm_pages = 100000 I copied this configuration to the new server and restarted postgres, which failed. The only message was [FAILED] at the end of the line. No other messages appeared on the console, no errors were logged to /var/log/pgsql, no errors were logged to /var/log/messages, except for this one: Jun 3 17:53:05 keel postgresql: Starting postgresql service: failed I ran "sh -x /etc/init.d/postgresql start", which gave no further information, but then tried the command that was being executed: runuser -l postgres -c '/usr/bin/postmaster -p 5432 -D '\''/var/lib/pgsql/data'\'' &' which finally reported: FATAL: max_fsm_pages must exceed max_fsm_relations * 16 which, despite being weirdly incorrect, at least explains why postgresql isn't starting. Version-Release number of selected component (if applicable): postgresql-server-7.4.8-1.RHEL4.1 How reproducible: Always Steps to Reproduce: 1. Cause a configuration error in data/postgresql.conf 2. Restart postgresql service. Actual Results: Observed no error messages explaining the cause of the service failure. Expected Results: FATAL errors should get logged to syslog and console, all other errors should at least make it to syslog. Additional info:
(In reply to comment #0) > max_fsm_relations = 10000 > max_fsm_pages = 100000 > FATAL: max_fsm_pages must exceed max_fsm_relations * 16 > > which, despite being weirdly incorrect, at least explains why postgresql isn't starting. (ok, not weird at all, but the actual error is irrelevant here; only that it was masked by the initscript)
Yeah, this is sort of a catch-22 situation. You can't really expect config-file errors to get reported to syslog, since it's only after reading the config file that the postmaster can know how to send stuff to syslog properly. The error is in fact reported to postmaster's stderr, and the problem is that the default setup in the initscript is to send stderr to /dev/null. Unfortunately we cannot readily change that default either, because due to the lack of any log-rotation capability in Postgres 7.*, any file we did send it to would grow without bound. This is fixed in Postgres 8.0, and our packaging of 8.0 does do something more intelligent with the default logging setup, but with 7.* there are no good alternatives. See also bug #103767
(In reply to comment #2) > The error is > in fact reported to postmaster's stderr, and the problem is that the default > setup in the initscript is to send stderr to /dev/null. Unfortunately we cannot > readily change that default either, because due to the lack of any log-rotation > capability in Postgres 7.*, any file we did send it to would grow without bound. Well, what about leaving it going to stderr, so that the operator running the initscript can see the FATAL messages, instead of redirecting it to /dev/null or a file? As long as the FATALs aren't masked, it doesn't matter where they go -- I don't want to jump through hoops to find out an error that postgres is trying to tell me.
I don't think that that would be a very workable solution; initscripts are normally not run interactively, and so having them write stuff to stderr is frowned upon. Ultimately, there just isn't any good solution for this in PG 7.*; which is why the upstream developers did a substantial amount of work to fix it in 8.0. There are also policy issues. With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating changes for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects. I don't think I could get approval for putting a short-term hack for this problem into RHEL4.