Strange issue with initdb on 8.0 and Solaris automounts

From: Kenneth Lareau <elessar(at)numenor(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Strange issue with initdb on 8.0 and Solaris automounts
Date: 2005-01-27 22:23:05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


I ran into an interesting issue when installing PostgreSQL 8.0 that I'm
not sure how to resolve correctly. My system is a Sun machine (Blade
1000) running Solaris 9, with relatively recent patches. After install-
ing 8.0, I went to run the 'initdb' command and was greeted with the

[delirium:postgres] ~
(11) 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.

creating directory /software/postgresql-8.0.0/data ... initdb: could not create directory "/software/postgresql-8.0.0": Operation not applicable

The error message was a bit confusing, so I decided to run a truss on
the process to see what might be happening, and this is what I came

8802/1: write(1, " c r e a t i n g d i r".., 62) = 62
8802/1: umask(0) = 077
8802/1: umask(077) = 0
8802/1: mkdir("/software", 0777) Err#17 EEXIST
8802/1: stat64("/software", 0xFFBFC858) = 0
8802/1: mkdir("/software/postgresql-8.0.0", 0777) Err#89 ENOSYS

The last error in that section, ENOSYS, is very strange, as the Solaris
manpage for 'mkdir' does not mention it as a possible error. One thing
to note in this, however, is that '/software/postgresql-8.0.0' is not a
regular directory, but an automount point (which in this case is just a
local loopback mount). So the indication is that Solaris seems to have
a bug not in mkdir, but deeper in their VFS code that's causing this
seemingly strange issue.

Two workarounds for this problem have been found: running 'initdb' with
a directory that's *not* an automount point and then moving the 'data'
directory to its final destination worked fine, along with a suggestion
from Andrew Dunstan (on the #postgresql IRC channel) with using a rela-
tive path for the data directory. Both were successful in avoiding the
issue, but I decided to mention this here in case someone felt it might
be worth looking into to see if the Sun problem can be avoided; I am
going to notify Sun of their bug, just don't know how long it will take
them to actually resolve it (if they ever do).

While I can fully understand that a code change here may not be desire-
able, might some notes in the documentation be useful for those who
might stumble across the problem as well? Just a suggestion...

I hope I gave sufficient information on the problem, though I'm always
willing to give any clarification needed. Thank you for your time.

Ken Lareau

Browse pgsql-hackers by date

  From Date Subject
Next Message David Parker 2005-01-27 22:49:37 Re: Strange issue with initdb on 8.0 and Solaris automounts
Previous Message Marc G. Fournier 2005-01-27 21:51:17 Re: Security Release Packaging ...