Description of problem: The initdb program fails. Here's the output I get: The files belonging to this database system will be owned by user "decker". This user must also own the server process. The database cluster will be initialized with locale en_US.UTF-8. fixing permissions on existing directory /home/decker/jurg/mydb... ok creating directory /home/decker/jurg/mydb/base... ok creating directory /home/decker/jurg/mydb/global... ok creating directory /home/decker/jurg/mydb/pg_xlog... ok creating directory /home/decker/jurg/mydb/pg_clog... ok selecting default max_connections... 10 selecting default shared_buffers... 50 creating configuration files... ok creating template1 database in /home/decker/jurg/mydb/base/1... initdb: failed Version-Release number of selected component (if applicable): postgresql-server-7.4.6-1.FC3.1 How reproducible: Every time Steps to Reproduce: 1. mkdir jurg 2. export PGDATA=/home/decker/jurg 3. Actual results: I get a failed error. Expected results: I expected it to initialize a database. Additional info:
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.