Thread: Initdb failing for no apparent reason in 8.0.0beta4 on windows

Hello,

We have been using postgres 8.0.0beta4 successfully on various windows
machines for a while now, but we have run across a particular windows
machine of one of our customers where initdb.exe is failing with an exit
code of 1 for no reason that I can determine.  The machine is running
windows 2000 (sp4, version 5.00.2195).  I have tested in-house
successfully on windows 2k (sp4, v5.00.2195 as well), windows 2k3, and
windows xp pro (sp2).

We created a non-administrator account (named "enetaware") on the customer
machine and given it "log-on-as-service" privileges (we ultimately run
postgres as a service using this account).  We have the postgresql bin,
lib, and share directories installed on the customer machine in
"C:\Program Files\EmprisaNetworks\E-NetAware\postgresql".  We execute the
following command while logged in using this account (-d and -n options
added temporarily for debugging):

initdb.exe -d -n -U ena -L "C:\Program
Files\EmprisaNetworks\E-NetAware\postgresql\share" --locale=C

The output from this command is:

Running in noclean mode.  Mistakes will not be cleaned up.
Running in debug mode.
VERSION=8.0.0beta4
PGDATA=C:/E-NetAware-Data/db
share_path=C:/Program Files/EmprisaNetworks/E-NetAware/postgresql/share
PGPATH=C:/Program Files/EmprisaNetworks/E-NetAware/postgresql/bin
POSTGRES_SUPERUSERNAME=ena
POSTGRES_BKI=C:/Program
Files/EmprisaNetworks/E-NetAware/postgresql/share/postgr
es.bki
POSTGRES_DESCR=C:/Program
Files/EmprisaNetworks/E-NetAware/postgresql/share/post
gres.description
POSTGRESQL_CONF_SAMPLE=C:/Program
Files/EmprisaNetworks/E-NetAware/postgresql/sh
are/postgresql.conf.sample
PG_HBA_SAMPLE=C:/Program
Files/EmprisaNetworks/E-NetAware/postgresql/share/pg_hb
a.conf.sample
PG_IDENT_SAMPLE=C:/Program
Files/EmprisaNetworks/E-NetAware/postgresql/share/pg_
ident.conf.sample
The files belonging to this database system will be owned by user "ena".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory C:/E-NetAware-Data/db ... initdb: failed

The exit code returned by initdb is "1".  Any ideas why this would be
failing?  I didn't see any similar report about this in the mailing list
archives.  My next step is to recompile initdb.exe and put in more
temporary debug print statements and have the customer retry it, however
that may take a while.

Thanks in advance.
Steve McWilliams

"Steve McWilliams" <smcwilliams@EmprisaNetworks.com> writes:
> We have been using postgres 8.0.0beta4 successfully on various windows
> machines for a while now, but we have run across a particular windows
> machine of one of our customers where initdb.exe is failing with an exit
> code of 1 for no reason that I can determine.

beta4 is way way back at this point.  Could you try it with RC3 or RC4?

            regards, tom lane

Nevermind, I found out what this was.  Turned out that the customer
machine in question had particularly heavy security settings and so the
enetaware account did not have permission to write into the directory
where it was trying to create PGDATA.  Once I widened the settings on the
parent directory then it worked fine.  Kind of odd that inidb.exe just
fails silently when this is the case however.

> Hello,
>
> We have been using postgres 8.0.0beta4 successfully on various windows
> machines for a while now, but we have run across a particular windows
> machine of one of our customers where initdb.exe is failing with an exit
> code of 1 for no reason that I can determine.  The machine is running
> windows 2000 (sp4, version 5.00.2195).  I have tested in-house
> successfully on windows 2k (sp4, v5.00.2195 as well), windows 2k3, and
> windows xp pro (sp2).
>
> We created a non-administrator account (named "enetaware") on the
> customer machine and given it "log-on-as-service" privileges (we
> ultimately run postgres as a service using this account).  We have the
> postgresql bin, lib, and share directories installed on the customer
> machine in
> "C:\Program Files\EmprisaNetworks\E-NetAware\postgresql".  We execute
> the following command while logged in using this account (-d and -n
> options added temporarily for debugging):
>
> initdb.exe -d -n -U ena -L "C:\Program
> Files\EmprisaNetworks\E-NetAware\postgresql\share" --locale=C
>
> The output from this command is:
>
> Running in noclean mode.  Mistakes will not be cleaned up.
> Running in debug mode.
> VERSION=8.0.0beta4
> PGDATA=C:/E-NetAware-Data/db
> share_path=C:/Program Files/EmprisaNetworks/E-NetAware/postgresql/share
> PGPATH=C:/Program Files/EmprisaNetworks/E-NetAware/postgresql/bin
> POSTGRES_SUPERUSERNAME=ena
> POSTGRES_BKI=C:/Program
> Files/EmprisaNetworks/E-NetAware/postgresql/share/postgr
> es.bki
> POSTGRES_DESCR=C:/Program
> Files/EmprisaNetworks/E-NetAware/postgresql/share/post
> gres.description
> POSTGRESQL_CONF_SAMPLE=C:/Program
> Files/EmprisaNetworks/E-NetAware/postgresql/sh
> are/postgresql.conf.sample
> PG_HBA_SAMPLE=C:/Program
> Files/EmprisaNetworks/E-NetAware/postgresql/share/pg_hb
> a.conf.sample
> PG_IDENT_SAMPLE=C:/Program
> Files/EmprisaNetworks/E-NetAware/postgresql/share/pg_
> ident.conf.sample
> The files belonging to this database system will be owned by user "ena".
> This user must also own the server process.
>
> The database cluster will be initialized with locale C.
>
> creating directory C:/E-NetAware-Data/db ... initdb: failed
>
> The exit code returned by initdb is "1".  Any ideas why this would be
> failing?  I didn't see any similar report about this in the mailing list
> archives.  My next step is to recompile initdb.exe and put in more
> temporary debug print statements and have the customer retry it, however
> that may take a while.
>
> Thanks in advance.
> Steve McWilliams


Steve McWilliams
Software Engineer
Emprisa Networks
703-691-0433x21
smcwilliams@emprisanetworks.com

The information contained in this communication is intended only for the
use of the recipient named above, and may be legally privileged,
confidential and exempt from disclosure under applicable law. If the
reader of this communication is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication, or any of its contents, is strictly prohibited. If you have
received this communication in error, please resend this communication to
the sender and delete the original communication and any copy of it from
your computer system. Thank you.

"Steve McWilliams" <smcwilliams@EmprisaNetworks.com> writes:
> Nevermind, I found out what this was.  Turned out that the customer
> machine in question had particularly heavy security settings and so the
> enetaware account did not have permission to write into the directory
> where it was trying to create PGDATA.  Once I widened the settings on the
> parent directory then it worked fine.  Kind of odd that inidb.exe just
> fails silently when this is the case however.

CVS tip says something:

...
creating directory /home/postgres/testversion/data ... initdb: could not create directory
"/home/postgres/testversion/data":Permission denied 
$

I believe this was fixed here:

2004-11-28 22:05  tgl

    * src/bin/initdb/initdb.c: Clean up initdb's error handling so that
    it prints something more useful than just 'failed' when there's a
    problem.  Per gripe from Chris Albertson.

The shell-script version of initdb relied heavily on the programs it
invoked (mkdir, in this case) to print error messages when something
went wrong, so the initial transliteration into a C program was
definitely on the strong silent side :-(

            regards, tom lane

Steve McWilliams wrote:

>Nevermind, I found out what this was.  Turned out that the customer
>machine in question had particularly heavy security settings and so the
>enetaware account did not have permission to write into the directory
>where it was trying to create PGDATA.  Once I widened the settings on the
>parent directory then it worked fine.  Kind of odd that inidb.exe just
>fails silently when this is the case however.
>
>
>

Very odd, since initdb calls chmod to fix the directory permissions, if
it already exists, and creates it with those same permissions if it
isn't (in both cases the permissions are 0700 ). If that isn't enough on
Windows, perhaps someone can tell us what is.

cheers

andrew