Strange issue with initdb on 8.0 and Solaris automounts

Coincidentally I JUST NOW built 8.0 on Solaris 9, and ran into the same
problem. As they say, "this used to work".....

We build databases as part of the build of our product, and I'm looking
into what we need to do to upgrade from 7.4.5, and this was the first
thing I ran into. I hadn't gotten as far as truss yet, so thanks Kenneth
for that extra info.

Did initdb previously just assume the -D path existed, and now it is
trying to create the whole path, if necessary?

- DAP

"David Parker" <dparker@tazznetworks.com> writes:

Did initdb previously just assume the -D path existed, and now it is
trying to create the whole path, if necessary?

Pre-8.0 it was using mkdir(1), which might possibly contain some weird
workaround for this case on Solaris.

I suppose that manually creating the data directory before running
initdb would also avoid this issue, since the mkdir(2) loop is only
entered if we don't find the directory in existence.

regards, tom lane

I tried that, and it just runs into the problem with the first sub dir
it tries to create:

ed9i03:/home/dparker/temp
% initdb -D /home/dparker/temp/testdb
The files belonging to this database system will be owned by user
"dparker".
This user must also own the server process.

The database cluster will be initialized with locale C.

fixing permissions on existing directory /home/dparker/temp/testdb ...
ok
creating directory /home/dparker/temp/testdb/global ... initdb: could
not create directory "/home/dparker": Operation not applicable
initdb: removing contents of data directory "/home/dparker/temp/testdb"
ed9i03:/home/dparker/temp

truss:

chmod("/home/dparker/temp/testdb", 0700) = 0
ok
write(1, " o k\n", 3) = 3
creating directory /home/dparker/temp/testdb/global ... write(1, " c r e
a t i n g d i r".., 56) = 56
umask(0) = 077
umask(077) = 0
mkdir("/home", 0777) Err#17 EEXIST
xstat(2, "/home", 0x08045C20) = 0
mkdir("/home/dparker", 0777) Err#89 ENOSYS
umask(077) = 077
fstat64(2, 0x08045000) = 0
initdbwrite(2, " i n i t d b", 6) = 6
: could not create directory "write(2, " : c o u l d n o t ".., 30)
= 30
/home/dparkerwrite(2, " / h o m e / d p a r k e".., 13) = 13
": write(2, " " : ", 3) = 3
Operation not applicablewrite(2, " O p e r a t i o n n o".., 24)
= 24

- DAP

In message <21723.1106868138@sss.pgh.pa.us>, Tom Lane writes:

"David Parker" <dparker@tazznetworks.com> writes:

Did initdb previously just assume the -D path existed, and now it is
trying to create the whole path, if necessary?

Pre-8.0 it was using mkdir(1), which might possibly contain some weird
workaround for this case on Solaris.

I suppose that manually creating the data directory before running
initdb would also avoid this issue, since the mkdir(2) loop is only
entered if we don't find the directory in existence.

regards, tom lane

Actually, creating the 'data' directory first doesn't work either:

[delirium:postgres] ~
(17) mkdir data
[delirium:postgres] ~
(18) initdb -D /software/postgresql-8.0.0/data
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.

fixing permissions on existing directory /software/postgresql-8.0.0/data ... ok
creating directory /software/postgresql-8.0.0/data/global ... initdb: could not create directory "/software/postgresql-8.0.0": Operation not applicable
initdb: removing contents of data directory "/software/postgresql-8.0.0/data"

Since there's subdirectories that need to be created, it still runs into
the problem. I don't know why the command 'mkdir' doesn't exhibit the
same problem as the function 'mkdir', but running:

mkdir /software/postgresql-8.0.0

produces the correct error "File exists" on my system. I suspect the
'mkdir' command probably checks to see if the directory exists first
before trying to create it, which avoids the problem.

Ken Lareau
elessar@numenor.org

Kenneth Lareau <elessar@numenor.org> writes:

In message <21723.1106868138@sss.pgh.pa.us>, Tom Lane writes:

I suppose that manually creating the data directory before running
initdb would also avoid this issue, since the mkdir(2) loop is only
entered if we don't find the directory in existence.

Actually, creating the 'data' directory first doesn't work either:

Good point.

I don't know why the command 'mkdir' doesn't exhibit the
same problem as the function 'mkdir', but running:

mkdir /software/postgresql-8.0.0

produces the correct error "File exists" on my system.

Could you truss that and see what it does? It would be a simple change
in initdb to make it stat before mkdir instead of after, but I'm not
totally convinced that would fix the problem. If mkdir returns a funny
error code then stat might as well ...

regards, tom lane

In message <22095.1106869848@sss.pgh.pa.us>, Tom Lane writes:

Kenneth Lareau <elessar@numenor.org> writes:

In message <21723.1106868138@sss.pgh.pa.us>, Tom Lane writes:

I suppose that manually creating the data directory before running
initdb would also avoid this issue, since the mkdir(2) loop is only
entered if we don't find the directory in existence.

Actually, creating the 'data' directory first doesn't work either:

Good point.

I don't know why the command 'mkdir' doesn't exhibit the
same problem as the function 'mkdir', but running:

mkdir /software/postgresql-8.0.0

produces the correct error "File exists" on my system.

Could you truss that and see what it does? It would be a simple change
in initdb to make it stat before mkdir instead of after, but I'm not
totally convinced that would fix the problem. If mkdir returns a funny
error code then stat might as well ...

regards, tom lane

Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0'
on my Solaris 9 system:

10832: umask(0) = 077
10832: umask(077) = 0
10832: mkdir("/software/postgresql-8.0.0", 0777) Err#89 ENOSYS
10832: stat64("/software/postgresql-8.0.0", 0xFFBFFA38) = 0
10832: fstat64(2, 0xFFBFEB78) = 0
10832: write(2, " m k d i r", 5) = 5
10832: write(2, " : ", 2) = 2
10832: write(2, " c a n n o t c r e a t".., 24) = 24
10832: write(2, " ` / s o f t w a r e / p".., 28) = 28
10832: write(2, " : ", 2) = 2
10832: write(2, " F i l e e x i s t s", 11) = 11
10832: write(2, "\n", 1) = 1
10832: _exit(1)

It's doing the stat after the mkdir attempt it seems, and coming back
with the correct response. Hmm, maybe I should look at the Solaris 8
code for the mkdir command...

Ken Lareau
elessar@numenor.org

Tom Lane wrote:

I don't know why the command 'mkdir' doesn't exhibit the
same problem as the function 'mkdir', but running:

mkdir /software/postgresql-8.0.0

produces the correct error "File exists" on my system.

Could you truss that and see what it does? It would be a simple change
in initdb to make it stat before mkdir instead of after, but I'm not
totally convinced that would fix the problem. If mkdir returns a funny
error code then stat might as well ...

There's also a tiny race condition, which I guess isn't worth worrying
about.

Returning ENOSYS is pretty bogus ...

cheers

andrew

Kenneth Lareau <elessar@numenor.org> writes:

In message <22095.1106869848@sss.pgh.pa.us>, Tom Lane writes:

Could you truss that and see what it does?

Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0'
on my Solaris 9 system:

10832: mkdir("/software/postgresql-8.0.0", 0777) Err#89 ENOSYS
10832: stat64("/software/postgresql-8.0.0", 0xFFBFFA38) = 0

It's doing the stat after the mkdir attempt it seems, and coming back
with the correct response. Hmm, maybe I should look at the Solaris 8
code for the mkdir command...

Well, the important point is that the stat does succeed. I'm not going
to put in anything as specific as a check for ENOSYS, but it seems
reasonable to try the stat first and mkdir only if stat fails.
I've applied the attached patch.

regards, tom lane

*** src/bin/initdb/initdb.c.orig	Sat Jan  8 17:51:12 2005
--- src/bin/initdb/initdb.c	Thu Jan 27 19:23:49 2005
***************
*** 476,481 ****
--- 476,484 ----
   * this tries to build all the elements of a path to a directory a la mkdir -p
   * we assume the path is in canonical form, i.e. uses / as the separator
   * we also assume it isn't null.
+  *
+  * note that on failure, the path arg has been modified to show the particular
+  * directory level we had problems with.
   */
  static int
  mkdir_p(char *path, mode_t omode)
***************
*** 544,573 ****
  		}
  		if (last)
  			(void) umask(oumask);
! 		if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) < 0)
  		{
! 			if (errno == EEXIST || errno == EISDIR)
! 			{
! 				if (stat(path, &sb) < 0)
! 				{
! 					retval = 1;
! 					break;
! 				}
! 				else if (!S_ISDIR(sb.st_mode))
! 				{
! 					if (last)
! 						errno = EEXIST;
! 					else
! 						errno = ENOTDIR;
! 					retval = 1;
! 					break;
! 				}
! 			}
! 			else
  			{
  				retval = 1;
  				break;
  			}
  		}
  		if (!last)
  			*p = '/';
--- 547,570 ----
  		}
  		if (last)
  			(void) umask(oumask);
! 
! 		/* check for pre-existing directory; ok if it's a parent */
! 		if (stat(path, &sb) == 0)
  		{
! 			if (!S_ISDIR(sb.st_mode))
  			{
+ 				if (last)
+ 					errno = EEXIST;
+ 				else
+ 					errno = ENOTDIR;
  				retval = 1;
  				break;
  			}
+ 		}
+ 		else if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) < 0)
+ 		{
+ 			retval = 1;
+ 			break;
  		}
  		if (!last)
  			*p = '/';

Andrew Dunstan <andrew@dunslane.net> writes:

There's also a tiny race condition, which I guess isn't worth worrying
about.

Considering that we're not checking ownership or permissions of the
parent directories, I'd say not.

regards, tom lane

In message <22687.1106872653@sss.pgh.pa.us>, Tom Lane writes:

Kenneth Lareau <elessar@numenor.org> writes:

In message <22095.1106869848@sss.pgh.pa.us>, Tom Lane writes:

Could you truss that and see what it does?

Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0'
on my Solaris 9 system:

10832: mkdir("/software/postgresql-8.0.0", 0777) Err#89 ENOSYS
10832: stat64("/software/postgresql-8.0.0", 0xFFBFFA38) = 0

It's doing the stat after the mkdir attempt it seems, and coming back
with the correct response. Hmm, maybe I should look at the Solaris 8
code for the mkdir command...

Well, the important point is that the stat does succeed. I'm not going
to put in anything as specific as a check for ENOSYS, but it seems
reasonable to try the stat first and mkdir only if stat fails.
I've applied the attached patch.

regards, tom lane

Tom, thank you very much for the patch, it worked like a charm.

Ken Lareau
elessar@numenor.org

Yes, thanks very much!

- DAP

Will this make it into 8.1?