Bug 142607

Oops, forgot to add step 3 on the steps to reproduce part.  Step 3
should be run 'initdb'.

Are you sure you aren't sending initdb's stderr to /dev/null?

The small values selected for max_connections and shared_buffers
suggest to me that there's something wrong with the platform's SysV
IPC support, but there really ought to be a message sent to stderr
about it, if so.

What is the platform exactly, anyway?  (hardware, OS version, kernel
version)

Try doing "ulimit -c unlimited" before the initdb, and see if you get
a core dump file.

I'm positive I'm not sending stderr to /dev/null.

The platform is x86, and I can be more specific if you want as far as
hardware goes.  The os is Fedora Core 3, running
kernel-smp-2.6.9-1.678_FC3.

I tried that ulimit command before the initdb but no core file ever
shows up and I still get the same error.

Hmm, it works perfectly fine on my FC3 machine.  I'm not running an
SMP kernel but I doubt that's the issue.

I'm still focused on the small connections/buffers numbers; that says
we're unable to create semaphores or shared memory, and there should
be an error message about that.

If you look at the initdb script, around line 568 you'll see a line
like
if "$PGPATH"/postgres -boot -x0 $TEST_OPT template1 </dev/null
>/dev/null 2>&1
Please remove the output redirections (>/dev/null 2>&1) and then try
running the script in the same environment as before.  You should
hopefully get a bunch of chatter at the "selecting default
max_connections" step.  That might give a bit of a clue.

Also, look in your system log (/var/log/messages) to see if running
the script causes anything to show up there.  I'm wondering if this
could be a selinux problem (what selinux settings are you using?)

Nothing different shows up when I get rid of that redirection, or on
the test for shared buffers if I remove that redirection.  And I don't
see anything appear in /var/log/messages either when I run initdb. 
The selinux setup I'm using is the targeted policy.

I think that I had this same error where initdb was failing and not
makeing template0|1 databases.  I was reading around and realized that
it might be an SELinux permissions error.  I did the following and now
I'm good to go.

Errors that I was getting in psql:

ERROR:  relation "pg_catalog.pg_user" does not exist
initdb was failing without error

>  su
%  /etc/init.d/postgresql stop
%  yes | rm -r /var/lib/pgsql/data/
%  mkdir /var/lib/pgsql/data/
%  chown postgres /var/lib/pgsql/data/
%  /usr/sbin/setenforce 0
%  /etc/init.d/postgresql start
%  su postgres
>  createuser <loginid>
>  exit
%  /usr/sbin/setenforce 1
%  exit
>  createdb
>  psql
#  \l  

My relavant setup:

kernel-2.6.9-1.681_FC3
kernel-module-ipw2200-2.6.9-1.681_FC3-0.16-0.lvn.1
kernel-module-ntfs-2.6.9-1.681_FC3-2.1.20-0.rr.3.3
kernel-utils-2.4-13.1.39
postgresql-7.4.6-1.FC3.2
postgresql-libs-7.4.6-1.FC3.2
postgresql-server-7.4.6-1.FC3.2
libselinux-1.19.1-8
selinux-policy-targeted-1.17.30-2.58

Glen, are you running SELinux in enforcement mode, and if so does
"sudo /usr/sbin/setenforce 0" make it work?  I've been able to produce
failures similar to yours under enforcement mode, because
selinux-policy-targeted disallows /usr/bin/postgres from accessing
stuff outside /var/lib/pgsql/data whether it's being run as a daemon
or not.  The lack of an error message is a bit annoying, and I'll see
about fixing that, but it's not too surprising considering that no one
in the Postgres project has ever seen a case where initdb was allowed
to write in a directory but postgres was not.

Yeah, I've got the targetted policy on and enforcing on.  I can
turning it off.  Just wondering though, I thought I read somewhere
that turning off selinux once it's on will maybe screw some things up.
 Is that not the case?

Adding Dan to cc list because this is starting to look a lot like a
selinux issue.

Dan, I just traced through this scenario to see why no helpful error
message got printed, and what I find is that the postgres executable
IS printing a message on stderr, to the effect that it cannot read the
config files initdb has set up.  Now, whether the policy should be
that way is debatable, but what's got me steamed at the moment is that
the error message isn't making it to my terminal.  I suppose somebody
thought it was a good idea to disallow daemons from writing on
/dev/tty, but I beg to differ.

I can demonstrate that it's selinux's fault because the error message
does appear when enforcement is off.

It's particularly annoying that selinux won't admit to having done
this: nothing at all gets printed in /var/log/messages.

Fwiw, I have a similar problem: Postgresql just refused to start.
Doing the setenforce 0 thing solved it. The exact lines in
/var/log/messages for an attempt to start postgresql are

Jan 19 19:23:19 fc3 kernel: audit(1106158999.695:0): avc:  denied  {
append } for  pid=5509 exe=/usr/bin/postgres path=/var/log/pgsql
dev=hdb1 ino=148114 scontext=root:system_r:postgresql_t
tcontext=user_u:object_r:var_log_t tclass=file
Jan 19 19:23:19 fc3 kernel: audit(1106158999.695:0): avc:  denied  {
append } for  pid=5509 exe=/usr/bin/postgres path=/var/log/pgsql
dev=hdb1 ino=148114 scontext=root:system_r:postgresql_t
tcontext=user_u:object_r:var_log_t tclass=file
Jan 19 19:23:19 fc3 kernel: audit(1106158999.700:0): avc:  denied  {
read } for  pid=5509 exe=/usr/bin/postgres name=PG_VERSION dev=hdb1
ino=148382 scontext=root:system_r:postgresql_t
tcontext=root:object_r:var_lib_t tclass=file
Jan 19 19:23:20 fc3 postgresql: ÐапÑÑкаÑÑÑÑÑ ÑлÑжба postgresql:  failed

(I have set PGLOG to /var/log/pgsql in /etc/init.d/postgresql)

restorecon -R -v /var/log/pgsql 
should fix the problem.

Dan

Dan,

Was selinux policy updated in order for this to work out of the box? If yes,
please close this.

Thanks

Marking as closed.  Please feel free to reopen if updating
selinux-policy-targeted and running the recommended restorecon command didn't
solve the problem.