I just finished installing the PGDG rpms on my second server. This one is a single CPU Opteron with 2 SATA based RAID5 arrays. (Just to clear things up, I know RAID5 is bad for postgres, but this is a storage server that has postgres only as a backup for the main machine.) The problem diesn'[t happen on this second machine. Which leaves me with one big difference between the two machines. The main DB server (the one with the problem) has the RAID10 array mounted exclusively for it's access, and under it the pg_xlog directory is mounted on another exclusive partition on the other array. Here are the mount details: /dev/sdb1 on /var/lib/pgsql type xfs (rw,noatime,nodiratime,logbufs=8) /dev/sda3 on /var/lib/pgsql/data/pg_xlog type ext2 (rw,noatime,nodiratime) Any idea if this might be causing the problem? I don't see how it might do it, but as I said I'm not an SELinux expert. Bye, Guy. On 3/3/06, Just Someone <just.some@xxxxxxxxx> wrote: > 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! > -- Bye, Guy Family management on rails: http://www.famundo.com - coming soon!
