Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 86CBE2E0035 for ; Wed, 28 May 2008 23:51:47 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 41231-03 for ; Wed, 28 May 2008 23:51:23 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id 4A4A12E0038 for ; Wed, 28 May 2008 23:51:29 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m4T2pP1x013919; Wed, 28 May 2008 22:51:25 -0400 (EDT) To: Steve Holdoway cc: pgsql-admin@postgresql.org Subject: Re: what happend to my database In-reply-to: <20080529135235.d6fcad87.steve.holdoway@firetrust.com> References: <8078a1730805281837y1ed331bey4e7db16a63423cfa@mail.gmail.com> <20080529135235.d6fcad87.steve.holdoway@firetrust.com> Comments: In-reply-to Steve Holdoway message dated "Thu, 29 May 2008 13:52:35 +1200" Date: Wed, 28 May 2008 22:51:25 -0400 Message-ID: <13918.1212029485@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/235 X-Sequence-Number: 29319 Steve Holdoway writes: > "Medi Montaseri" wrote: >> I think the following happend... >> Since my PGDATA was on an iSCSI device, by the time /etc/rc3.d/S64postgresql >> was executed, the device below it was not available.....question...why the >> error says "permission denied" vs "file not found". In the meantime, pg_ctl >> kept trying and finally concluded that the data directory is blank, and >> hence this must be a out-of-box case and he is good to initdb the PGDATA and >> as it called initdb to do the job... the iSCSI volume below it came online >> and by then the bomb had already been dropped. >> >> Now I need to find some facts to support this... > When you mount a partition on linux, it does this by overlaying it's root directory with the existing one on the parent volume. Ownerships and permissions are also replaced. I expect that the /qmsvol directory will be owned by root, with fairly restrictive access rights. This will not be the case the root ( . ) directory on the external device, which will be postgres-friendly. >> Where else can I look for forensics > I don't think you need any more! To fix this, I'd do 2 things. First, start postgres much later in the boot sequence: > cd /etc/rc3.d ; mv S64postgresql S99postgresql > ( and the same in rc5.d if you're using a gui at all ). The other thing to do is remove the auto-initdb behavior in your startup script. We've done that in recent releases because of prior reports of this type of problem. The OP's script is evidently still old-school, though. regards, tom lane