From scheidell@scanner.secnap.net  Sat Nov 30 11:28:50 2002
Return-Path: <scheidell@scanner.secnap.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 87F4037B401
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 30 Nov 2002 11:28:50 -0800 (PST)
Received: from hackertrap.secnap.net (scanner.secnap.net [208.237.120.133])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 1A05943EC2
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 30 Nov 2002 11:28:46 -0800 (PST)
	(envelope-from scheidell@scanner.secnap.net)
Received: from hackertrap.secnap.net (localhost [127.0.0.1])
	by hackertrap.secnap.net (8.12.6/8.11.3) with ESMTP id gAUJSeiB010148
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 30 Nov 2002 14:28:40 -0500 (EST)
	(envelope-from scheidell@scanner.secnap.net)
Received: (from root@localhost)
	by hackertrap.secnap.net (8.12.6/8.12.6/Submit) id gAUJSeDR010147;
	Sat, 30 Nov 2002 14:28:40 -0500 (EST)
Message-Id: <200211301928.gAUJSeDR010147@hackertrap.secnap.net>
Date: Sat, 30 Nov 2002 14:28:40 -0500 (EST)
From: Michael Scheidell <scheidell@secnap.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: postgres7 can't create initial database.
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         45877
>Category:       ports
>Synopsis:       postgres7 can't create initial database.
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-ports
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Nov 30 11:30:01 PST 2002
>Closed-Date:    Thu Jan 02 18:36:49 PST 2003
>Last-Modified:  Thu Jan 02 18:36:49 PST 2003
>Originator:     Michael Scheidell
>Release:        FreeBSD 4.7-STABLE i386
>Organization:
SECNAP
>Environment:
System: FreeBSD hackertrap.secnap.net 4.7-STABLE FreeBSD 4.7-STABLE #6: Fri Nov 22 08:40:01 EST 2002 scheidell@hackertrap.secnap.net:/usr/obj/usr/src/sys/HACKERTRAP i386


>Description:
	postgres ver 7.2.3
	postgres7 initdb program doesn't create directory.
	needs -p option.
	Example:
	su -l pgsql -c initdb
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.

creating directory /usr/local/pgsql/data... ok
creating directory /usr/local/pgsql/data/base... ok
creating directory /usr/local/pgsql/data/global... ok
creating directory /usr/local/pgsql/data/pg_xlog... ok
creating directory /usr/local/pgsql/data/pg_clog... ok
creating template1 database in /usr/local/pgsql/data/base/1... Bad system
call (core dumped)

initdb failed.
>How-To-Repeat:
	cd /usr/ports/postgres7
	make install
>Fix:

Add in the -p option to mkdir.

 diff -bBru initdb.orig initdb
--- initdb.orig Sat Nov 30 14:14:12 2002
+++ initdb      Sat Nov 30 14:22:34 2002
@@ -461,7 +461,7 @@
 $ECHO_N "creating template1 database in $PGDATA/base/1... "$ECHO_C

 rm -rf "$PGDATA"/base/1 || exit_nicely
-mkdir "$PGDATA"/base/1 || exit_nicely
+mkdir -p "$PGDATA"/base/1 || exit_nicely

 # Top level PG_VERSION is checked by bootstrapper, so make it first
 echo "$short_version" > "$PGDATA/PG_VERSION" || exit_nicely

>Release-Note:
>Audit-Trail:

From: Palle Girgensohn <girgen@pingpong.net>
To: freebsd-gnats-submit@FreeBSD.org, scheidell@secnap.net
Cc:  
Subject: Re: ports/45877: postgres7 can't create initial database.
Date: Sat, 30 Nov 2002 21:11:40 +0100

 > creating directory /usr/local/pgsql/data... ok
 > creating directory /usr/local/pgsql/data/base... ok
 ...
 
 > creating template1 database in /usr/local/pgsql/data/base/1... Bad system
 > call (core dumped)
 
 Odd, it just created the data/base dir, how come it needs mkdir -p to 
 create data/base/1 ?
 
 I've never experienced this problem. See if the newly comitted 
 postgrsql-7.3 helps. It is in PR ports/45879
 
 Regards,
 Palle
 
 

From: Palle Girgensohn <girgen@pingpong.net>
To: freebsd-gnats-submit@FreeBSD.org, scheidell@secnap.net
Cc:  
Subject: Re: ports/45877: postgres7 can't create initial database.
Date: Mon, 30 Dec 2002 21:10:38 +0100

 Please close this PR.
 
 Problem was fixed by adding SYSV support to the kernel:
 options         SYSVSHM                 #SYSV-style shared memory
 options         SYSVSEM                 #SYSV-style semaphores
 
 /Palle
 
State-Changed-From-To: open->closed 
State-Changed-By: edwin 
State-Changed-When: Thu Jan 2 18:36:09 PST 2003 
State-Changed-Why:  
PR closed, problem solved. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=45877 
>Unformatted:
