Hi Tom, > Hmm. That seems like a SELinux policy bug. It doesn't happen for me: > the pid file is created with the same context the other files have.
I agree! I have the latest FC4 policy update. So I downloaded the sources as the new one didn't solve the issue. The policy source has no mention on the pid file, but it seems like it should be created with the settings of the directory, which is set correctly. I'm not an expert in SELinux, so I didn't want to mess with the policy, though I think the pid file could be added to the policy specifically to solve this issue. Also, I did run restorecon on the directory (that was the first thing I tried), but it didn't help. Probably because the pid file isn't there when postgres isn't running. Today I will have the results from my second machine update, as it just finished installing all the FC4 updates through yum. I'll let you know how it goes. Bye, Guy. > > -rw------- postgres postgres root:object_r:postgresql_db_t postmaster.pid > > Are you sure that your SELinux policy is up-to-date? Maybe you need to > do a restorecon on the postgres binaries and/or /var/lib/pgsql/data. > > > Some more info about the system: > > * FC4 fully updated > > * Postgres 8.1.3 built from the PGDG SRPMs > > * Dual Opteron > > I tried it myself on a freshly-updated FC4 x86_64 system, using the current > FC5 SRPMs, and couldn't see a problem. Red Hat's SRPMs are not exactly > like the PGDG ones, but the only difference I can find that looks at all > relevant to SELinux is this one in the init script: > > 132c134 > < [ -x /usr/bin/chcon ] && /usr/bin/chcon -u system_u -r > object_r -t postgresql_log_t "$PGLOG" > --- > > [ -x /usr/bin/chcon ] && /usr/bin/chcon -t postgresql_log_t > > "$PGLOG" > > and that's not about the pid file. > > regards, tom lane > -- Bye, Guy Family management on rails: http://www.famundo.com - coming soon! ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
