Hi Tom,
I looked into another system I have and after updating FC4 to the
latest and installing the latest from the PGDG srpms, I didn't have
this problem.
Tomorrow I'm going to do a similar test on another server that I have
to install Postgres on. I will report back with what I find on it. But
on this machine the change to su solved the issue.
Some more clues that might help you see if there's a real problem, is
that the /var/lib/pgsql/data/postmaster.pid file is created with the a
SELinux context that's different from the rest. It is created with
system_u:object_r:file_t while the rest of the files are created with
root:object_r:postgresql_db_t. And the postmaster (when using runuser)
fails on accessing it according to the audit log. The file is created
but it's empty. So the failure is when trying to write the pid and the
rest of the info to it. When I run with su, it is be able to access it
just fine. I retested now just to make sure I wasn't seeing things.
Some more info about the system:
* FC4 fully updated
* Postgres 8.1.3 built from the PGDG SRPMs
* Dual Opteron
* 4GB RAM
* /var/lib/pgsql/data on a RAID10 with xfs on top
* WAL on a different RAID on a partition only for itself with ext2
* SELinux in targeted policy mode
Bye,
Guy.
On 3/1/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Just Someone" <just.some@gmail.com> writes:
> > I researched it a bit, and tried a few things, and discovered that the
> > problem is in the init script at /etc/init.d/postgres users runuser
> > instead of su on SELinux enabled systems. But for some reason it won't
> > work this way. I manually reveted it to use su and it works fine.
>
> I don't think I believe this ... not least because the runuser-for-su
> substitution has been in there for a long time. It doesn't explain
> a breakage during an FC4 update.
>
> Can you provide a reasonably self-contained demonstration of the problem
> you saw?
>
> regards, tom lane
>
--
Bye,
Guy
Family management on rails: http://www.famundo.com - coming soon!
