Обсуждение: Problem with initdb -W
I have an IRC report, confirmed, that in RC2 initdb -W (set super-user password) fails: $ initdb -WThe files belonging to this database system will be owned by user"postgres".This user must also own the serverprocess.The database cluster will be initialized with locale C.creating directory /u/pg/data... okcreating directory/u/pg/data/base... okcreating directory /u/pg/data/global... okcreating directory /u/pg/data/pg_xlog... okcreatingdirectory /u/pg/data/pg_clog... okcreating template1 database in /u/pg/data/base/1... okcreating configurationfiles... okinitializing pg_shadow... okEnter new superuser password: Enter it again: setting password... Thegroup file wasn't generated. Please report this problem.initdb failed.Removing /u/pg/data. Of course, the obvious solution is not to use -W. ;-) I will research this but I wanted to report it right away. My only guess is that the standalone backend to alter the super-user password is messing up things: "$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null <<EOF ALTER USER "$POSTGRES_SUPERUSERNAME" WITH PASSWORD '$FirstPw'; -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
It was easier than I thought. As I now remember, it is not a problem if pg_pwd or pg_group don't exist. Initdb should check for pg_pwd because it just added a password, so it better exist, but there is no reason for pg_group to exist at this point. I will patch 7.3 and current CVS. I don't think this warrants another RC candidate. This is the type of cleanup we will be doing to the 7.3 branch for the next few months anyway as part of minor releases. --------------------------------------------------------------------------- Bruce Momjian wrote: > I have an IRC report, confirmed, that in RC2 initdb -W (set super-user > password) fails: > > $ initdb -W > The files belonging to this database system will be owned by user > "postgres". > This user must also own the server process. > > The database cluster will be initialized with locale C. > > creating directory /u/pg/data... ok > creating directory /u/pg/data/base... ok > creating directory /u/pg/data/global... ok > creating directory /u/pg/data/pg_xlog... ok > creating directory /u/pg/data/pg_clog... ok > creating template1 database in /u/pg/data/base/1... ok > creating configuration files... ok > initializing pg_shadow... ok > Enter new superuser password: > Enter it again: > setting password... > The group file wasn't generated. Please report this problem. > > initdb failed. > Removing /u/pg/data. > > Of course, the obvious solution is not to use -W. ;-) > > I will research this but I wanted to report it right away. My only > guess is that the standalone backend to alter the super-user password is > messing up things: > > "$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null <<EOF > ALTER USER "$POSTGRES_SUPERUSERNAME" WITH PASSWORD '$FirstPw'; > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> I have an IRC report, confirmed, that in RC2 initdb -W (set super-user > password) fails: > > Enter new superuser password: > Enter it again: > setting password... > The group file wasn't generated. Please report this problem. > > initdb failed. > Removing /u/pg/data. I had actually experienced this problem as well on a one-off test machine. However I just put it down to weirdness and didn't follow it up...sorry... Chris
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> It was easier than I thought. As I now remember, it is not a problem if
> pg_pwd or pg_group don't exist. Initdb should check for pg_pwd because
> it just added a password, so it better exist, but there is no reason for
> pg_group to exist at this point.
I think I may have induced this problem during this change:
Revision 1.113 / (download) - annotate - [select for diffs] , Mon Oct 21 19:46:45 2002 UTC (5 weeks ago) by tgl CVS
Tags:REL7_3_STABLE, HEAD Changes since 1.112: +144 -67 linesDiff to previous 1.112 Make CREATE/ALTER/DROP USER/GROUP
transaction-safe,or at least prettynearly so, by postponing write of flat password file until transactioncommit.
I modified user.c to keep track separately of pg_shadow and pg_group
changes, so that it would write only the file it needed to. Before
that, it probably *was* true that the initial assignment of a password
to the superuser would cause both pg_pwd and an empty pg_group to be
created. Too bad it didn't occur to me to test initdb -W :-(
> I will patch 7.3 and current CVS. I don't think this warrants another
> RC candidate.
Agreed, removal of an incorrect error check seems pretty safe ...
regards, tom lane