syslog logging setup broken?
Nic Ferrier (nferrier@tapsellferrier.co.uk) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
syslog logging setup broken?
Long Description
When building from the latest (7.1 beta 4+) CVS I had a problem with syslog logging.
Every time I started the postmaster the logger would fail with the message:
logger: FATAL 1: 'syslog' is not a valid option name
I eventually tracked this down to being something to do with the postgresql.conf file's specifiying of the logging.
I fixed the problem by commenting out the command to turn on syslog terminal log output.
This led me to examine the startup file supplied for Linux users in more detail. I believe it's broken.
See the example code below.
BTW in case you need to know my system is a Sun running Debian (2.2).
Sample Code
My postgresql.conf looks a bit like this:
# turn on logging of connections
log_connections = on
# make all logs go to syslog and terminal
# (TF run Postgres with no terminal mostly
# but it's usefull when debugging)
# syslog = 1
When the syslog=1 statement is NOT commented out the server won't start.
The relevant part of the startup file, which I copied from the RedHat example, looks like this:
if [ ${USE_SYSLOG} = "yes" ]; then
su - ${PGACCOUNT} -c "(${POSTMASTER} -D ${PGDATA} ${PGOPTS} 2>&1
| logger -p ${FACILITY}.notice) &" > /dev/null 2>&1 &
else
su - ${PGACCOUNT} -c "${POSTMASTER} -D ${PGDATA} ${PGOPTS}
${PGLOGFILE} 2>&1 &" > /dev/null 2>&1 &
fi
Now surely this will cause either the syslog or a tmp file to recieve output but not both.
Unless there's something inside the postmaster itself that does these logging operations, in which case the startup file doesn't need to pipe to the logger.
No file was uploaded with this report
Nic Ferrier (nferrier@tapsellferrier.co.uk) reports a bug with a severity of 3
The relevant part of the startup file, which I copied from the RedHat example, looks like this:
The example startup file is outdated and broken. Don't use it.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
The example startup file is outdated and broken. Don't use it.
Er ... shouldn't we fix it? Or remove it?
regards, tom lane
Tom Lane writes:
Peter Eisentraut <peter_e@gmx.net> writes:
The example startup file is outdated and broken. Don't use it.
Er ... shouldn't we fix it? Or remove it?
See my message on -hackers, "Sparc/Linux patch" thing follow-up.
The bottom line is that, IMHO, writing a portable init.d style (or any
other such concept) startup file that is ready for blind use is beyond
practicality. It might be better to collect a few of the ones that are
being used now (Red Hat-style, SuSE-style, Debian, *BSD-style) and ship
them. This should be coordinated with the packagers, though.
I'll try to look into it.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Tom Lane writes:
Peter Eisentraut <peter_e@gmx.net> writes:
The example startup file is outdated and broken. Don't use it.
Er ... shouldn't we fix it? Or remove it?
See my message on -hackers, "Sparc/Linux patch" thing follow-up.
The bottom line is that, IMHO, writing a portable init.d style (or any
other such concept) startup file that is ready for blind use is beyond
practicality. It might be better to collect a few of the ones that are
being used now (Red Hat-style, SuSE-style, Debian, *BSD-style) and ship
them. This should be coordinated with the packagers, though.
Should I remove init.d from /contrib?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> 04-Feb-01 10:07:40 PM >>>
The bottom line is that, IMHO, writing a portable
init.d style (or any other such concept) startup file
that is ready for blind use is beyond practicality.
It might be better to collect a few of the ones that are
being used now (Red Hat-style, SuSE-style, Debian,
*BSD-style) and ship them. This should be coordinated
with the packagers, though.
Should I remove init.d from /contrib?
I'm just a postgres user but I don't agree with Peter. I think the
file is valuable.
The file is valuable for people not using a distribution such as
Debian, etc... and also is usefull to people developing packages for
distributions.
I don't use a packaged postgres and it was certainly valuable to me
because it served as an example of what I had to do to get postgres
going quickly in the way that I wanted.
I sent Peter an updated file that IMHO irons out some problems which
may cause Peter to consider the file broken:
- ouptut was being piped to the logger if "syslog" was on
It's not necessary to do that because postgres handles the decision
about syslog depending on the conf file.
- the postmaster was being started without nohup
- the system for setting options wasn't very usefull
the system that I've replaced it with isn't terribly usefull either
but it works.
So anyway, my view as a user is that it's usefull and that a package
specific version would come with the package anyway.
Nic Ferrier
Tapsell-Ferrier Limited
Import Notes
Resolved by subject fallback
Nic Ferrier writes:
Should I remove init.d from /contrib?
I'm just a postgres user but I don't agree with Peter. I think the
file is valuable.
I didn't say it wasn't valuable, I just said it didn't work...
This problem seems to call for a more general solution than a handful of
example style files.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Import Notes
Reply to msg id not found: sa7dd9d4.081@tapsellferrier.co.uk | Resolved by subject fallback
"Nic Ferrier" wrote:
- the postmaster was being started without nohup
If postmaster is being started by init, it should not need nohup, because
init never exits and postmaster is not going to get shutdown unexpectedly.
nohup has a performance cost, in that (at least on Linux) it automatically
nices (lowers the priority of) the process. You may not want the
priority lowered...
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Lift up your heads, O ye gates; and be ye lift up, ye
everlasting doors; and the King of glory shall come
in. Who is this King of glory? The LORD strong and
mighty, the LORD mighty in battle."
Psalms 24:7,8
"Oliver Elphick" <olly@lfix.co.uk> writes:
"Nic Ferrier" wrote:
- the postmaster was being started without nohup
If postmaster is being started by init, it should not need nohup, because
init never exits and postmaster is not going to get shutdown unexpectedly.
On the other hand, when pg_ctl is invoked by hand, it probably is a bug
that it fails to use nohup. Perhaps this is a reason why pg_ctl should
not be made into a substitute for a startup script?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> 06-Feb-01 12:39:24 AM >>>
"Nic Ferrier" wrote:
- the postmaster was being started without nohup
Oliver wrote:
If postmaster is being started by init, it should not need
nohup, because init never exits and postmaster is not
going to get shutdown unexpectedly.
I agree... I was just putting into the script what was in the man
page about postmaster.
The man page suggests that nohup is required to init postmaster, I
know this isn't true but to implement an example init file and not
match up with the man page seemed foolish.
I guess nohup would stop postmaster doing something awfull if it
doesn't handle HUP properly but I very much doubt that you guys fail
to handle HUP.
Nic
Import Notes
Resolved by subject fallback
If postmaster is being started by init, it should not need nohup, because
init never exits and postmaster is not going to get shutdown unexpectedly.On the other hand, when pg_ctl is invoked by hand, it probably is a bug
that it fails to use nohup. Perhaps this is a reason why pg_ctl should
not be made into a substitute for a startup script?
If pg_ctl unconditionally use nohup, it might be a performance penalty
as Oliver mentioned.
nohup has a performance cost, in that (at least on Linux) it automatically
nices (lowers the priority of) the process. You may not want the
priority lowered...
Moreover if postmaster detaches itself to be a deamon, nohup is not
necessary at all.
BTW, for the startup script, I don't think we need to use pg_ctl.
Invoking postmaster directry seems enough for me. The only reason for
using pg_ctl to start postmaster is waiting for postmaster up and
running. In most cases the time to recover DB would not be so
long. And if the recovery took too long time, we would not want to be
blocked in the middle of the boot sequence anyway.
Comments?
--
Tatsuo Ishii
Tatsuo Ishii writes:
Moreover if postmaster detaches itself to be a deamon, nohup is not
necessary at all.
Right. Scrap that thought then.
BTW, for the startup script, I don't think we need to use pg_ctl.
Invoking postmaster directry seems enough for me. The only reason for
using pg_ctl to start postmaster is waiting for postmaster up and
running.
Waiting for the postmaster to start up is really only useful when you
start it interactively, either during development, or if you need to
repair a problem. In either of these cases you might as well (and
probably rather should) look at the log output yourself, i.e., just use
'postmaster'.
In most cases the time to recover DB would not be so
long. And if the recovery took too long time, we would not want to be
blocked in the middle of the boot sequence anyway.
Exactly. No waiting on startup by default then?
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
The man page suggests that nohup is required to init postmaster, I
know this isn't true but to implement an example init file and not
match up with the man page seemed foolish.I guess nohup would stop postmaster doing something awfull if it
doesn't handle HUP properly but I very much doubt that you guys fail
to handle HUP.
Good point. postmaster in 7.1 uses HUP signal to re-read
postgresql.conf. It seems we should not use nohup to start postmaster.
--
Tatsuo Ishii