Thread: Cannot get postgres started on Fedora core 3

System: 1.5 GB memory; 160 GB hard drive with 140 GB free (plenty of space
in the database directories); 1.5 Mhz AMD Athlon processor.
    - Fedora Core 3 with all fixes applied
    - Postgres 7.4 as supplied by up2date (RedHat network)

I've been trying to get postgres to start on my machine for a few days (on
and off) and have not been successful in understanding why it will not
start.

It had been running fine for several weeks as the database backend to the
OpenGroupware server. One day, it would not start (service postgres start
[FAILED] ) I do not know the cause of the failure, it could have been a
power failure that caused an unclean shutdown, it could have been too big of
a file going into the team server (OpenGroupware), or ??

I've tried to shutdown and restart the Linux server several times. Postgres
fails to start in the startup. [FAILED]

I've tried every way possible to start postmaster and postgres to no avail,
including using pg_ctl.

I can't find any logs to tell my why it is failing, and the only book I
have, "Practical PostgreSQL" is of no help.

The conf files are standard with only minor modifications to allow the tcp
port, etc.

Please point me in the right direction! Thanks!

Mark

"Mark Travis" <marktrav@bellsouth.net> writes:
> I've been trying to get postgres to start on my machine for a few days (on
> and off) and have not been successful in understanding why it will not
> start.

The pre-8.0 RPMs have a bad habit of sending the postmaster log to
/dev/null :-(.  You could edit /etc/rc.d/init.d/postgresql to point
the log (i.e. postmaster's stderr) someplace more useful, or change the
postgresql.conf file to log to syslog instead of stderr.  Once you have
hold of the postmaster's dying words, let us know ...

            regards, tom lane

I've placed several "echo" statements into /etc/rc.d/init.d/postgresql to
see what branches the scripts are executing and what the variables are.

I've narrowed it down to the final call
$SU -l postgres -c "$PGENGINE/postmaster -p
(snipped the rest of the line from this post because it's the standard line
in the file)

All of the env variables are correctly set in this statement, but no pid is
generated.

If I manually enter the command on the command line

postgres -c /usr/bin/postmaster -p 5432 -D /var/lib/pgsql

I get nothing.... not even a warning that I shouldn't start postgres as
root.

If I just type "postgres" on the command line.... nothing. No warnings, no
nothing.....

Mark
> I've been trying to get postgres to start on my machine for a few days (on
> and off) and have not been successful in understanding why it will not
> start.

>The pre-8.0 RPMs have a bad habit of sending the postmaster log to
>/dev/null :-(.  You could edit /etc/rc.d/init.d/postgresql to point
>the log (i.e. postmaster's stderr) someplace more useful, or change the
>postgresql.conf file to log to syslog instead of stderr.  Once you have
>hold of the postmaster's dying words, let us know ...

>            regards, tom lane

"Mark Travis" <marktrav@bellsouth.net> writes:
> If I manually enter the command on the command line
> postgres -c /usr/bin/postmaster -p 5432 -D /var/lib/pgsql
> I get nothing.... not even a warning that I shouldn't start postgres as
> root.
> If I just type "postgres" on the command line.... nothing. No warnings, no
> nothing.....

I'll bet you have SELinux enforcement on.  One of the less fun
properties of that thing (at least in Red Hat's current "targeted"
policy) is that it forbids daemons from writing on /dev/tty.  And
the postgres executable is classified as a daemon even when you
invoke it from the command line.  Net result: no error messages.

Does it work any better after "sudo /usr/sbin/setenforce 0" ?

            regards, tom lane

On Thu, Mar 17, 2005 at 05:16:34PM -0500, Mark Travis wrote:
> I've placed several "echo" statements into /etc/rc.d/init.d/postgresql to
> see what branches the scripts are executing and what the variables are.

Just for the record: it's much easier to debug shell scripts by doing

sh -x /etc/rc.d/init.d/postgresql start

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Having your biases confirmed independently is how scientific progress is
made, and hence made our great society what it is today" (Mary Gardiner)

Tom, I owe you bigtime. That was exactly the problem. I would remove selinux
from my machine if I wasn't worried that it wasn't actually protecting me
from the outside world. I had problems installing OpenGroupware as well with
selinux, but I thought I had them resolved. I bet it got overwritten on an
update cycle.

I guess I better get educated on selinux so I can turn it on and off at will
without it driving the rest of my system insane.

Is there a config file I can change to keep that from happening in the
future?

Thanks again!

Mark

> If I manually enter the command on the command line
> postgres -c /usr/bin/postmaster -p 5432 -D /var/lib/pgsql
> I get nothing.... not even a warning that I shouldn't start postgres as
> root.
> If I just type "postgres" on the command line.... nothing. No warnings, no
> nothing.....

I'll bet you have SELinux enforcement on.  One of the less fun
properties of that thing (at least in Red Hat's current "targeted"
policy) is that it forbids daemons from writing on /dev/tty.  And
the postgres executable is classified as a daemon even when you
invoke it from the command line.  Net result: no error messages.

Does it work any better after "sudo /usr/sbin/setenforce 0" ?

            regards, tom lane

"Mark Travis" <marktrav@bellsouth.net> writes:
> Tom, I owe you bigtime. That was exactly the problem. I would remove selinux
> from my machine if I wasn't worried that it wasn't actually protecting me
> from the outside world. I had problems installing OpenGroupware as well with
> selinux, but I thought I had them resolved. I bet it got overwritten on an
> update cycle.

selinux is definitely still a work-in-progress.  I think eventually it
will be a great security tool, but right now it's a real PITA to work
with --- they're a long way from having all the rough edges filed down,
in terms of writing a policy that will allow standard daemons to do
what they've traditionally done.  I have to take some of the blame here,
because I should have done more testing while FC3 was still internal to
Red Hat.  I did not realize how invasive selinux really is :-(

            regards, tom lane