I've seen reports of that before, eg,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152931
but it's far from clear why some people see this and some don't.
I feel such a goof ball. I searched bugzilla for an hour yesterday but
for some reason I did not find that bug. But that solved my problem. I
just set sleep 3 and now it works.
I still get the /usr/bin/chcon message but only when I run the command
by hand, even after upgrading coreutils:
# PGLOG=/home/postgres/pgstartup.log
# touch "$PGLOG"
# ls -Z $PGLOG
-rw-r--r-- root root
/home/postgres/pgstartup.log
# chown postgres:postgres "$PGLOG"
# chmod go-rwx "$PGLOG"
# /usr/bin/chcon -u system_u -r object_r -t postgresql_log_t "$PGLOG"
/usr/bin/chcon: can't apply partial context to unlabeled file
/home/postgres/pgstartup.log
# ls -Z $PGLOG
-rw------- postgres postgres
/home/postgres/pgstartup.log
# uname -r
2.6.11-1.1286_FC4
# rpm -qf /usr/bin/chcon
coreutils-5.2.1-48
I will try upgrading the kernel to see if that will resolve that issue.
That is going to give you some problems if you have SELinux in
enforcement mode, because the standard policy will disallow the
postgres
daemon from writing anywhere under /home.
I really should take the time and learn SELinux but I'm crunched right
now and will disable it for now.
Thank you soooooo much for the all the help.
Dianne
On Jun 7, 2005, at 10:58 AM, Tom Lane wrote:
Dianne Yumul <dianne@xxxxxxxxxxxxxxx> writes:
# rm -f pgstartup.log
# /etc/rc.d/init.d/postgresql start
/usr/bin/chcon: can't apply partial context to unlabeled file
/home/postgres/pgstartup.log
Starting postgresql service: [FAILED]
# ps aux | grep postmaster
postgres 10470 34.1 0.6 112404 5248 pts/0 S 09:24 0:02
/usr/bin/postmaster -p 5432 -D /home/postgres/data
root 10480 0.0 0.0 3756 668 pts/0 R+ 09:24 0:00 grep
postmaster
Odd. I don't see any reason that you'd not get the OK message, given
that the postmaster started. I've seen reports of that before, eg,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152931
but it's far from clear why some people see this and some don't.
In any case I suspect that the FAILED message is unrelated to the chcon
problem.
ls -Z /home/postgres/pgstartup.log
Gives:
Sorry, this option can only be used on a SELinux kernel.
But after setting selinux to permissive mode, ls -Z
/home/postgres/pgstartup.log gives:
-rw------- postgres postgres system_u:object_r:postgresql_log_t
/home/postgres/pgstartup.log
There is something very flaky about either your kernel or your selinux
utilities. Are you up-to-date on kernel version? (Let's see ... my
FC3 machine is at 2.6.11-1.14_FC3, and I think I may be behind ...)
I tried to reproduce the problem by doing what the initscript does,
without any success:
[tgl@rh1 ~]$ sudo mkdir /home/postgres
[tgl@rh1 ~]$ sudo chown postgres:postgres /home/postgres
[tgl@rh1 ~]$ PGLOG=/home/postgres/pgstartup.log
[tgl@rh1 ~]$ sudo touch "$PGLOG"
[tgl@rh1 ~]$ sudo ls -Z $PGLOG
-rw-r--r-- root root root:object_r:user_home_t
/home/postgres/pgstartup.log
[tgl@rh1 ~]$ sudo chown postgres:postgres "$PGLOG"
[tgl@rh1 ~]$ sudo chmod go-rwx "$PGLOG"
[tgl@rh1 ~]$ sudo /usr/bin/chcon -u system_u -r object_r -t
postgresql_log_t "$PGLOG"
[tgl@rh1 ~]$ sudo ls -Z $PGLOG
-rw------- postgres postgres system_u:object_r:postgresql_log_t
/home/postgres/pgstartup.log
[tgl@rh1 ~]$ uname -r
2.6.11-1.14_FC3
[tgl@rh1 ~]$ rpm -qf /usr/bin/chcon
coreutils-5.2.1-31
so I suspect that what you are running into is either a kernel bug or a
chcon bug; it'd be worth making sure both kernel and coreutils are up
to
date. If you try the sequence by hand, what do you get?
Oh, and is the message really complaining
about /home/postgres/pgstartup.log? AFAICS the initscript should be
messing with /var/lib/pgsql/pgstartup.log.
Sorry, I forgot to mention that I changed some of the defaults via
/etc/sysconfig/pgsql/postgresql file, which looks like this:
PGDATA=/home/postgres/data
PGLOG=/home/postgres/pgstartup.log
That is going to give you some problems if you have SELinux in
enforcement mode, because the standard policy will disallow the
postgres
daemon from writing anywhere under /home. You can fix this by fooling
around with the policy and/or manually relabeling the database
directory
and files, but the path of least resistance is probably to leave the
database directory in the normal place.
regards, tom lane
---------------------------(end of
broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
