Re: staring pgsql on fedora 8 - Mailing list pgsql-general

From Anirban Banerjee
Subject Re: staring pgsql on fedora 8
Date
Msg-id 2aa7d70a0803062232h6ddae65exc124cc83ba61129f@mail.gmail.com
Whole thread Raw
In response to Re: staring pgsql on fedora 8  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Wow! thanks for being super helpful, I will try it all out. Though I distinctly remember turning off SElinux because it was giving me such a headache even in permissive mode.

Thanks again for the tips.
Regards,
-A

On Thu, Mar 6, 2008 at 10:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
newbiegalore <banerjee.anirban@gmail.com> writes:
> hey! thanks for the reply :-). I looked into the pgstartup.log file
> and everything seems to have worked perfectly with the msg at the end
> saying "Success: you can now start...."

> but when I try to start it as a normal user using su normaluser my
> computer just hangs.. arrrrgh!!!!

Try to start *what* as a normal user?

If you mean the Postgres postmaster, you're not supposed to start it as
a normal user; it has to run as the user "postgres" because of the
permissions on the database files.  The usual way to start or stop
the postmaster in a standard RPM installation is "sudo /sbin/service
postgresql start" (vice "stop").  Once you've got that working you can
make the service start automatically at system boot (see chkconfig).

> I found the exact
> problem described at http://www.computing.net/linux/wwwboard/forum/29077.html
> and at http://www.centos.org/modules/newbb/viewtopic.php?topic_id=12082
> but the solution is vague to me and using sudo doesn't help either.

If that's your problem then it's a generic issue having nothing much to
do with Postgres.  What it sounds like to me is a SELinux problem ...
if things magically start working after "sudo /usr/sbin/setenforce 0"
then that guess is confirmed.  I wouldn't recommend that as a permanent
solution though.  My best guess as to the cause is that you've got some
files that are labeled with the wrong SELinux context.  The solution
Red Hat recommends is

       touch /.autorelabel
       reboot

The presence of /.autorelabel causes the boot process to reset every
installed file's security label according to what the RPM database says
it should be (sort of like a fsck for permissions, and yeah it'll take a
little while).

                       regards, tom lane



--
"The reason Santa is so jolly is because he knows where all the bad girls live."
-George Carlin

pgsql-general by date:

Previous
From: Greg Smith
Date:
Subject: Re: shared_buffers and shmmax what are the max recommended values?
Next
From: Achmad Nizar Hidayanto
Date:
Subject: Re: Ask ctid