BUG #5680: Failure to start: too many private dirs demanded

Started by Alexey Parshinover 15 years ago6 messagesbugs
Jump to latest
#1Alexey Parshin
alexeyp@gmail.com

The following bug has been logged online:

Bug reference: 5680
Logged by: Alexey Parshin
Email address: alexeyp@gmail.com
PostgreSQL version: 9.0.0
Operating system: Gentoo Linux
Description: Failure to start: too many private dirs demanded
Details:

PostgreSQL (fresh install) fails to start.
The only message in the log file says:
FATAL: too many private dirs demanded

strace pg_ctl start -D/var/lib/postgresql/9.0/data shows (tail):

read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb77e4000, 4096) = 0
open("/usr/lib/postgresql-9.0/share/locale/en_AU.UTF-8/LC_MESSAGES/pg_ctl-9.
0.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/postgresql-9.0/share/locale/en_AU.utf8/LC_MESSAGES/pg_ctl-9.0
.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/postgresql-9.0/share/locale/en_AU/LC_MESSAGES/pg_ctl-9.0.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/postgresql-9.0/share/locale/en.UTF-8/LC_MESSAGES/pg_ctl-9.0.m
o", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/postgresql-9.0/share/locale/en.utf8/LC_MESSAGES/pg_ctl-9.0.mo
", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/postgresql-9.0/share/locale/en/LC_MESSAGES/pg_ctl-9.0.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77e4000
write(1, "server starting\n", 16server starting
) = 16
exit_group(0) = ?
FATAL: too many private dirs demanded

#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Alexey Parshin (#1)
Re: BUG #5680: Failure to start: too many private dirs demanded

Excerpts from Alexey Parshin's message of lun sep 27 16:56:01 -0400 2010:

The following bug has been logged online:

Bug reference: 5680
Logged by: Alexey Parshin
Email address: alexeyp@gmail.com
PostgreSQL version: 9.0.0
Operating system: Gentoo Linux
Description: Failure to start: too many private dirs demanded
Details:

PostgreSQL (fresh install) fails to start.
The only message in the log file says:
FATAL: too many private dirs demanded

Weird. A result of some gentoo patch perhaps? Please try

strace postmaster -D /var/lib/postgresql/9.0/data
which should be more illuminating.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alvaro Herrera (#2)
Re: BUG #5680: Failure to start: too many private dirs demanded

Alvaro Herrera <alvherre@commandprompt.com> writes:

Excerpts from Alexey Parshin's message of lun sep 27 16:56:01 -0400 2010:

PostgreSQL (fresh install) fails to start.
The only message in the log file says:
FATAL: too many private dirs demanded

Weird. A result of some gentoo patch perhaps? Please try

Is it possible that gentoo has more than 32 levels of subdirectory
underneath /usr/share/timezone (or whatever the local equivalent is)?

regards, tom lane

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alexey Parshin (#1)
Re: BUG #5680: Failure to start: too many private dirs demanded

Please trace the postmaster, not pg_ctl, as Alvaro suggested
(or else add the -f flag to the strace call).

regards, tom lane

#5Alexey Parshin
alexeyp@gmail.com
In reply to: Tom Lane (#4)
Re: BUG #5680: Failure to start: too many private dirs demanded

Sorry. My bad :)
After tracing postmaster as Alvaro suggested, I found the following fragment
(one of thousand):

stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0
stat64("/usr/share/zoneinfo/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Australia/Eucla",
{st_mode=S_IFREG|0644, st_size=446, ...}) = 0
open("/usr/share/zoneinfo",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 24
getdents64(24, /* 70 entries */, 32768) = 2032
close(24) = 0

And then found a link /usr/share/zoneinfo/Australia/Australia to
/usr/share/zoneinfo/Australia/Australia. Clearly, this isn't PostgreSQL
fault. Removing that link solved it. Thanks a lot.
A simple suggestion that would help in diagnostics: A message like 'too many
dir entries demanded' is more useful if the path in question is shown. For
example, a message like:

*Too many dir entries demanded. The path is
"/usr/share/zoneinfo/Australia/Australia/Australia/Australia/Eucla"*

gives the exact clue on what's wrong and doesn't require developer's time.

I'm really grateful for your help,
Alexey

On 29 September 2010 00:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Please trace the postmaster, not pg_ctl, as Alvaro suggested
(or else add the -f flag to the strace call).

regards, tom lane

--
Alexey Parshin,
http://www.sptk.net

#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alexey Parshin (#5)
Re: BUG #5680: Failure to start: too many private dirs demanded

Alexey Parshin <alexeyp@gmail.com> writes:

And then found a link /usr/share/zoneinfo/Australia/Australia to
/usr/share/zoneinfo/Australia/Australia. Clearly, this isn't PostgreSQL
fault. Removing that link solved it. Thanks a lot.

Ah-hah.

A simple suggestion that would help in diagnostics: A message like 'too many
dir entries demanded' is more useful if the path in question is shown. For
example, a message like:

*Too many dir entries demanded. The path is
"/usr/share/zoneinfo/Australia/Australia/Australia/Australia/Eucla"*

Hmm, not sure this sort of thing has ever come up before. But certainly
we can expend a couple more bytes on that error message. Done in HEAD.

regards, tom lane