[GENERAL] initdb error
I'm running into the following error message when running initdb (FreeBSD host): ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug The files belonging to this database system will be owned by user pgsql. This user must also own the server process. The database cluster will be initialized with locales COLLATE: C CTYPE:en_US.UTF-8 MESSAGES: en_US.UTF-8 MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default text search configuration will be set to english. creating directory /zdb/pgsql/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory child process exited with exit code 1 initdb: removing data directory /zdb/pgsql/data My best guess is that it has something to do with permissions, but I really have no idea. Has anyone seen this before and found a way around it? -David -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
David I just tried installing PG 9.2.2 on FreeBSD 8.3 and initdb went smoothly without any problems. the only difference would be that I had it running in a virtualbox instance. My config were as follows; FreeBSD 8.3-RELEASE-p5 (binary updated through freebsd-update) PG 9.2.2 (installed through ports) root filesystem on UFS ZFS mounted on /example PG data directory set to /example/pgsql/data relevant rc.conf entries: postgresql_enable=YES postgresql_data=/example/pgsql/data running /usr/local/etc/rc.d/postgresql initdb works perfectly. Just needed to set the correct permissions on /example/pgsql directory. Amitabh On Sat, Dec 15, 2012 at 10:32 AM, David Noel david.i.n...@gmail.com wrote: You need to talk to some FreeBSD kernel hackers about why link() might be failing here. Since you see it on UFS too, we can probably exonerate the ZFS filesystem-specific code. I did some googling and found that EPERM can be issued if the filesystem doesn't support hard links (which shouldn't apply to ZFS I trust). Also, Linux has a protected_hardlinks option that causes certain attempts at creating hard links to fail --- but our use-case here doesn't fall foul of any of those restrictions AFAICS, and of course FreeBSD isn't Linux. Still, I wonder if you're running into some misdesigned or misimplemented security restriction. You might want to look at your kernel parameters and see if any of them look like they might have to do with restricting hard-link operations. Also, since Amitabh failed to duplicate the failure on both earlier and later FreeBSD kernels, and we've not heard reports of this from anybody else either, it seems more than possible that it's a plain old bug in the specific kernel version you're using. As a short-term workaround, I'd suggest rebuilding with HAVE_WORKING_LINK disabled. (Just remove that #define from src/include/pg_config_manual.h and rebuild.) OK, thanks. I've gotten in touch with the freebsd-hackers mailing list. Hopefully we'll be able to get this one figured out. I compiled a GENERIC kernel and tried it again. Still no luck. But at least we know now it wasn't a configuration error.
Re: [GENERAL] initdb error
Ugh. It turns out I had security.bsd.hardlink_check_gid=1 and security.bsd.hardlink_check_uid=1 in sysctl.conf. Setting them to 0 fixed everything. That's frustrating. Sorry for all the trouble. Many thanks for helping resolve this. On 12/15/12, Amitabh Kant amitabhk...@gmail.com wrote: David I just tried installing PG 9.2.2 on FreeBSD 8.3 and initdb went smoothly without any problems. the only difference would be that I had it running in a virtualbox instance. My config were as follows; FreeBSD 8.3-RELEASE-p5 (binary updated through freebsd-update) PG 9.2.2 (installed through ports) root filesystem on UFS ZFS mounted on /example PG data directory set to /example/pgsql/data relevant rc.conf entries: postgresql_enable=YES postgresql_data=/example/pgsql/data running /usr/local/etc/rc.d/postgresql initdb works perfectly. Just needed to set the correct permissions on /example/pgsql directory. Amitabh On Sat, Dec 15, 2012 at 10:32 AM, David Noel david.i.n...@gmail.com wrote: You need to talk to some FreeBSD kernel hackers about why link() might be failing here. Since you see it on UFS too, we can probably exonerate the ZFS filesystem-specific code. I did some googling and found that EPERM can be issued if the filesystem doesn't support hard links (which shouldn't apply to ZFS I trust). Also, Linux has a protected_hardlinks option that causes certain attempts at creating hard links to fail --- but our use-case here doesn't fall foul of any of those restrictions AFAICS, and of course FreeBSD isn't Linux. Still, I wonder if you're running into some misdesigned or misimplemented security restriction. You might want to look at your kernel parameters and see if any of them look like they might have to do with restricting hard-link operations. Also, since Amitabh failed to duplicate the failure on both earlier and later FreeBSD kernels, and we've not heard reports of this from anybody else either, it seems more than possible that it's a plain old bug in the specific kernel version you're using. As a short-term workaround, I'd suggest rebuilding with HAVE_WORKING_LINK disabled. (Just remove that #define from src/include/pg_config_manual.h and rebuild.) OK, thanks. I've gotten in touch with the freebsd-hackers mailing list. Hopefully we'll be able to get this one figured out. I compiled a GENERIC kernel and tried it again. Still no luck. But at least we know now it wasn't a configuration error. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
David Noel david.i.n...@gmail.com writes: Ugh. It turns out I had security.bsd.hardlink_check_gid=1 and security.bsd.hardlink_check_uid=1 in sysctl.conf. Setting them to 0 fixed everything. That's frustrating. Sorry for all the trouble. Many thanks for helping resolve this. Hah, I wondered if it might be something like that. Still, it's hard to see how this link() would fail any security check that didn't amount to disabling link() altogether. The UID and GID of the process, the old file, and the directory will all match --- so exactly what rule are we falling foul of? (Or IOW, this still seems like a kernel bug, though perhaps of a design rather than implementation kind.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
I wrote: Hah, I wondered if it might be something like that. Still, it's hard to see how this link() would fail any security check that didn't amount to disabling link() altogether. The UID and GID of the process, the old file, and the directory will all match --- so exactly what rule are we falling foul of? (Or IOW, this still seems like a kernel bug, though perhaps of a design rather than implementation kind.) Ah, I found your thread on freebsd-hackers, and it looks like Konstantin Belousov has the answer: The sysctl indeed has an interesting interaction with the fact that the created inode inherits gid from the parent directory. If you use it, you must ensure that the directory group is in the group set of the process. IOW, the problem is that you'd created $PGDATA with group wheel, but this wasn't a group that the initdb process belonged to. It's a bit weird that of all the operations initdb had tried so far, only the link() would fail, but there you have it. Anyway the takeaway for us is that it's bad that the link() failure per se didn't get logged; this might have been less mystifying if it was. I've started a thread on pgsql-hackers about fixing the bootstrap-time logging rules for that. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
Well this has definitely moved up a support level and past anything I know about. For the record what version of FreeBSD are you running in case someone is searching the archives? Any help is always appreciated. FreeBSD 8.3-RELEASE-p5. (I wonder if upgrading to 9.1 would do anything..) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
Did you use ports to install postgresql? Yes What is the version of postgresql and freebsd you are using? postgresql client and server v. 9.2.2. If all else fails I could try downgrading to a previous version of postgres. FreeBSD 8.3-RELEASE-p5 I am getting a different output while running the initdb command through the rc script, and it's not using the -D path to initialize the cluster, it falls back to the default location /usr/local/pgsql/data . Setting postgresql_data=/usr/local/pgsql1/data in /etc/rc.conf makes it initialize at the right location . I did not had to mess with an permissions and the rc commands were all run as root. The above was tested on FreeBSD 9.1 with Postgresql 9.2 on UFS. I didn't have any luck with the rc script but I was able to use it to get a ktrace dump as root (ktrace as user pgsql doesn't seem to work). So hopefully that will show something(!) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On Fri, Dec 14, 2012 at 4:28 PM, David Noel david.i.n...@gmail.com wrote: Did you use ports to install postgresql? Yes What is the version of postgresql and freebsd you are using? postgresql client and server v. 9.2.2. If all else fails I could try downgrading to a previous version of postgres. FreeBSD 8.3-RELEASE-p5 I am getting a different output while running the initdb command through the rc script, and it's not using the -D path to initialize the cluster, it falls back to the default location /usr/local/pgsql/data . Setting postgresql_data=/usr/local/pgsql1/data in /etc/rc.conf makes it initialize at the right location . I did not had to mess with an permissions and the rc commands were all run as root. The above was tested on FreeBSD 9.1 with Postgresql 9.2 on UFS. I didn't have any luck with the rc script but I was able to use it to get a ktrace dump as root (ktrace as user pgsql doesn't seem to work). So hopefully that will show something(!) David If it helps, my versions were FreeBSD 8.1 + PG 9.0.5 using UFS on a dedicated server and FreeBSD 9.1 (available on FTP sites but not announced yet) + PG 9.2.2 using UFS on a virtual box instance. Looks like ZFS is the only major variable here. Amitabh
Re: [GENERAL] initdb error
On 12/13/12, David Noel david.i.n...@gmail.com wrote: I'm running into the following error message when running initdb (FreeBSD host): ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug The files belonging to this database system will be owned by user pgsql. This user must also own the server process. The database cluster will be initialized with locales COLLATE: C CTYPE:en_US.UTF-8 MESSAGES: en_US.UTF-8 MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default text search configuration will be set to english. creating directory /zdb/pgsql/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory child process exited with exit code 1 initdb: removing data directory /zdb/pgsql/data My best guess is that it has something to do with permissions, but I really have no idea. Has anyone seen this before and found a way around it? -David Interestingly, I have a second--virtually identical--server that I just tried initdb on. FreeBSD 8.3-RELEASE-p5, postgresql-server-9.2.2. Exact same FATAL: could not open file pg_xlog error. So it is reproducible. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/14/2012 04:08 AM, David Noel wrote: Interestingly, I have a second--virtually identical--server that I just tried initdb on. FreeBSD 8.3-RELEASE-p5, postgresql-server-9.2.2. Exact same FATAL: could not open file pg_xlog error. So it is reproducible. Does virtually identical extend to architecture, amd64? -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
Interestingly, I have a second--virtually identical--server that I just tried initdb on. FreeBSD 8.3-RELEASE-p5, postgresql-server-9.2.2. Exact same FATAL: could not open file pg_xlog error. So it is reproducible. Does virtually identical extend to architecture, amd64? Yes... and hardware. They only vary in the amount of CPU cache--one has twice the other. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
David Noel david.i.n...@gmail.com writes: I didn't have any luck with the rc script but I was able to use it to get a ktrace dump as root (ktrace as user pgsql doesn't seem to work). So hopefully that will show something(!) The relevant part of the ktrace output is 71502 postgres CALL unlink(0x7fffc130) 71502 postgres NAMI pg_xlog/xlogtemp.71502 71502 postgres RET unlink -1 errno 2 No such file or directory 71502 postgres CALL open(0x7fffc130,O_RDWR|O_CREAT|O_EXCL,S_IRUSR|S_IWUSR) 71502 postgres NAMI pg_xlog/xlogtemp.71502 71502 postgres RET open 3 71502 postgres CALL write(0x3,0x801a56030,0x2000) 71502 postgres GIO fd 3 wrote 4096 bytes a lot of uninteresting write() calls snipped ... 71502 postgres RET write 8192/0x2000 71502 postgres CALL close(0x3) 71502 postgres RET close 0 71502 postgres CALL unlink(0x7fffbc60) 71502 postgres NAMI pg_xlog/00010001 71502 postgres RET unlink -1 errno 2 No such file or directory 71502 postgres CALL link(0x7fffc130,0x7fffbc60) 71502 postgres NAMI pg_xlog/xlogtemp.71502 71502 postgres NAMI pg_xlog/00010001 71502 postgres RET link -1 errno 1 Operation not permitted 71502 postgres CALL unlink(0x7fffc130) 71502 postgres NAMI pg_xlog/xlogtemp.71502 71502 postgres RET unlink 0 71502 postgres CALL open(0x7fffc530,O_RDWR,unused0x180) 71502 postgres NAMI pg_xlog/00010001 71502 postgres RET open -1 errno 2 No such file or directory This corresponds to the execution of XLogFileInit(), and what's evidently happening is that we successfully create and zero-fill the first xlog segment file under a temporary name, but then the attempt to rename it into place with link() fails with EPERM. This is really a WTF kind of failure, I think. The directory is certainly writable --- it was made under our own UID, and what's more we just managed to create the file there under its temp name. So how can we get an EPERM failure from link()? I think this is a kernel bug. regards, tom lane PS: one odd thing here is that the ereport(LOG) in InstallXLogFileSegment isn't doing anything; otherwise we'd have gotten a much more helpful error report about could not link file. I don't think we run the bootstrap mode with log_min_messages set high enough to disable LOG messages, so why isn't it printing? Nonetheless, this error shouldn't have occurred. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/14/12, Tom Lane t...@sss.pgh.pa.us wrote: David Noel david.i.n...@gmail.com writes: I didn't have any luck with the rc script but I was able to use it to get a ktrace dump as root (ktrace as user pgsql doesn't seem to work). So hopefully that will show something(!) The relevant part of the ktrace output is 71502 postgres CALL unlink(0x7fffc130) 71502 postgres NAMI pg_xlog/xlogtemp.71502 71502 postgres RET unlink -1 errno 2 No such file or directory 71502 postgres CALL open(0x7fffc130,O_RDWR|O_CREAT|O_EXCL,S_IRUSR|S_IWUSR) 71502 postgres NAMI pg_xlog/xlogtemp.71502 71502 postgres RET open 3 71502 postgres CALL write(0x3,0x801a56030,0x2000) 71502 postgres GIO fd 3 wrote 4096 bytes a lot of uninteresting write() calls snipped ... 71502 postgres RET write 8192/0x2000 71502 postgres CALL close(0x3) 71502 postgres RET close 0 71502 postgres CALL unlink(0x7fffbc60) 71502 postgres NAMI pg_xlog/00010001 71502 postgres RET unlink -1 errno 2 No such file or directory 71502 postgres CALL link(0x7fffc130,0x7fffbc60) 71502 postgres NAMI pg_xlog/xlogtemp.71502 71502 postgres NAMI pg_xlog/00010001 71502 postgres RET link -1 errno 1 Operation not permitted 71502 postgres CALL unlink(0x7fffc130) 71502 postgres NAMI pg_xlog/xlogtemp.71502 71502 postgres RET unlink 0 71502 postgres CALL open(0x7fffc530,O_RDWR,unused0x180) 71502 postgres NAMI pg_xlog/00010001 71502 postgres RET open -1 errno 2 No such file or directory This corresponds to the execution of XLogFileInit(), and what's evidently happening is that we successfully create and zero-fill the first xlog segment file under a temporary name, but then the attempt to rename it into place with link() fails with EPERM. This is really a WTF kind of failure, I think. The directory is certainly writable --- it was made under our own UID, and what's more we just managed to create the file there under its temp name. So how can we get an EPERM failure from link()? I think this is a kernel bug. regards, tom lane PS: one odd thing here is that the ereport(LOG) in InstallXLogFileSegment isn't doing anything; otherwise we'd have gotten a much more helpful error report about could not link file. I don't think we run the bootstrap mode with log_min_messages set high enough to disable LOG messages, so why isn't it printing? Nonetheless, this error shouldn't have occurred. Thanks so much for the analysis. Where to from here? The freebsd-datab...@freebsd.org mailing list? The postgresql port maintainer? Who should I be in touch with? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
David Noel david.i.n...@gmail.com writes: On 12/14/12, Tom Lane t...@sss.pgh.pa.us wrote: This corresponds to the execution of XLogFileInit(), and what's evidently happening is that we successfully create and zero-fill the first xlog segment file under a temporary name, but then the attempt to rename it into place with link() fails with EPERM. This is really a WTF kind of failure, I think. The directory is certainly writable --- it was made under our own UID, and what's more we just managed to create the file there under its temp name. So how can we get an EPERM failure from link()? I think this is a kernel bug. Thanks so much for the analysis. Where to from here? The freebsd-datab...@freebsd.org mailing list? The postgresql port maintainer? Who should I be in touch with? You need to talk to some FreeBSD kernel hackers about why link() might be failing here. Since you see it on UFS too, we can probably exonerate the ZFS filesystem-specific code. I did some googling and found that EPERM can be issued if the filesystem doesn't support hard links (which shouldn't apply to ZFS I trust). Also, Linux has a protected_hardlinks option that causes certain attempts at creating hard links to fail --- but our use-case here doesn't fall foul of any of those restrictions AFAICS, and of course FreeBSD isn't Linux. Still, I wonder if you're running into some misdesigned or misimplemented security restriction. You might want to look at your kernel parameters and see if any of them look like they might have to do with restricting hard-link operations. Also, since Amitabh failed to duplicate the failure on both earlier and later FreeBSD kernels, and we've not heard reports of this from anybody else either, it seems more than possible that it's a plain old bug in the specific kernel version you're using. As a short-term workaround, I'd suggest rebuilding with HAVE_WORKING_LINK disabled. (Just remove that #define from src/include/pg_config_manual.h and rebuild.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
You need to talk to some FreeBSD kernel hackers about why link() might be failing here. Since you see it on UFS too, we can probably exonerate the ZFS filesystem-specific code. I did some googling and found that EPERM can be issued if the filesystem doesn't support hard links (which shouldn't apply to ZFS I trust). Also, Linux has a protected_hardlinks option that causes certain attempts at creating hard links to fail --- but our use-case here doesn't fall foul of any of those restrictions AFAICS, and of course FreeBSD isn't Linux. Still, I wonder if you're running into some misdesigned or misimplemented security restriction. You might want to look at your kernel parameters and see if any of them look like they might have to do with restricting hard-link operations. Also, since Amitabh failed to duplicate the failure on both earlier and later FreeBSD kernels, and we've not heard reports of this from anybody else either, it seems more than possible that it's a plain old bug in the specific kernel version you're using. As a short-term workaround, I'd suggest rebuilding with HAVE_WORKING_LINK disabled. (Just remove that #define from src/include/pg_config_manual.h and rebuild.) OK, thanks. I've gotten in touch with the freebsd-hackers mailing list. Hopefully we'll be able to get this one figured out. I compiled a GENERIC kernel and tried it again. Still no luck. But at least we know now it wasn't a configuration error. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] initdb error
I'm running into the following error message when running initdb (FreeBSD host): ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug The files belonging to this database system will be owned by user pgsql. This user must also own the server process. The database cluster will be initialized with locales COLLATE: C CTYPE:en_US.UTF-8 MESSAGES: en_US.UTF-8 MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default text search configuration will be set to english. creating directory /zdb/pgsql/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory child process exited with exit code 1 initdb: removing data directory /zdb/pgsql/data My best guess is that it has something to do with permissions, but I really have no idea. Has anyone seen this before and found a way around it? -David -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/2012 07:38 AM, David Noel wrote: I'm running into the following error message when running initdb (FreeBSD host): ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug The files belonging to this database system will be owned by user pgsql. This user must also own the server process. The database cluster will be initialized with locales COLLATE: C CTYPE:en_US.UTF-8 MESSAGES: en_US.UTF-8 MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default text search configuration will be set to english. creating directory /zdb/pgsql/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory child process exited with exit code 1 initdb: removing data directory /zdb/pgsql/data My best guess is that it has something to do with permissions, but I really have no idea. Has anyone seen this before and found a way around it? Not quite what is in the the init script in rc.d, have you tried running the initdb command directly? As you say I believe there are permissions problems. So following the instructions found below may solve your problem: http://www.postgresql.org/docs/9.2/interactive/app-initdb.html -David -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/12, Adrian Klaver adrian.kla...@gmail.com wrote: On 12/13/2012 07:38 AM, David Noel wrote: I'm running into the following error message when running initdb (FreeBSD host): ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug The files belonging to this database system will be owned by user pgsql. This user must also own the server process. The database cluster will be initialized with locales COLLATE: C CTYPE:en_US.UTF-8 MESSAGES: en_US.UTF-8 MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default text search configuration will be set to english. creating directory /zdb/pgsql/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory child process exited with exit code 1 initdb: removing data directory /zdb/pgsql/data My best guess is that it has something to do with permissions, but I really have no idea. Has anyone seen this before and found a way around it? Not quite what is in the the init script in rc.d, have you tried running the initdb command directly? As you say I believe there are permissions problems. So following the instructions found below may solve your problem: http://www.postgresql.org/docs/9.2/interactive/app-initdb.html -David -- Adrian Klaver adrian.kla...@gmail.com I've tried initdb directly: initdb -D /zdb/pgsql/data ...and also through pg_ctl: pg_ctl initdb -D /zdb/pgsql/data ...and still seem to wind up with the error: creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory -David -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/2012 08:18 AM, David Noel wrote: On 12/13/12, Adrian Klaver adrian.kla...@gmail.com wrote: On 12/13/2012 07:38 AM, David Noel wrote: I'm running into the following error message when running initdb (FreeBSD host): ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug The files belonging to this database system will be owned by user pgsql. This user must also own the server process. The database cluster will be initialized with locales COLLATE: C CTYPE:en_US.UTF-8 MESSAGES: en_US.UTF-8 MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default text search configuration will be set to english. creating directory /zdb/pgsql/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory child process exited with exit code 1 initdb: removing data directory /zdb/pgsql/data My best guess is that it has something to do with permissions, but I really have no idea. Has anyone seen this before and found a way around it? Not quite what is in the the init script in rc.d, have you tried running the initdb command directly? As you say I believe there are permissions problems. So following the instructions found below may solve your problem: http://www.postgresql.org/docs/9.2/interactive/app-initdb.html -David -- Adrian Klaver adrian.kla...@gmail.com I've tried initdb directly: initdb -D /zdb/pgsql/data ...and also through pg_ctl: pg_ctl initdb -D /zdb/pgsql/data ...and still seem to wind up with the error: creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory You are doing the above as the database user ex:postgres? The database user has permissions on /zdb/pgsql/data? -David -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
David Noel david.i.n...@gmail.com writes: I've tried initdb directly: initdb -D /zdb/pgsql/data ...and still seem to wind up with the error: creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory Hm, that eliminates my first theory that the rc.d script is using initdb's --xlogdir switch to try to put pg_xlog someplace that doesn't exist on your system. But it seems like this must be some variant of that. A simple permissions problem is not very credible, because at this point initdb has successfully made the data directory and a bunch of files within it already. You could get more information by using the --noclean switch to prevent removal of the datadir after failure, and then having a look at the debris. Is there a pg_xlog subdirectory inside /zdb/pgsql/data, and if so what permissions has it got? Perhaps it is not a directory, but a symlink to somewhere else? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On Thu, Dec 13, 2012 at 10:00 PM, Adrian Klaver adrian.kla...@gmail.comwrote:
On 12/13/2012 08:18 AM, David Noel wrote:
On 12/13/12, Adrian Klaver adrian.kla...@gmail.com wrote:
On 12/13/2012 07:38 AM, David Noel wrote:
I'm running into the following error message when running initdb
(FreeBSD
host):
ygg# /usr/local/etc/rc.d/postgresql initdb -D /zdb/pgsql/data --debug
The files belonging to this database system will be owned by user
pgsql.
This user must also own the server process.
The database cluster will be initialized with locales
COLLATE: C
CTYPE:en_US.UTF-8
MESSAGES: en_US.UTF-8
MONETARY: en_US.UTF-8
NUMERIC: en_US.UTF-8
TIME: en_US.UTF-8
The default text search configuration will be set to english.
creating directory /zdb/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 32MB
creating configuration files ... ok
creating template1 database in /zdb/pgsql/data/base/1 ... FATAL:
could not open file pg_xlog/**00010001 (log file 0,
segment 1): No such file or directory
child process exited with exit code 1
initdb: removing data directory /zdb/pgsql/data
My best guess is that it has something to do with permissions, but I
really have no idea. Has anyone seen this before and found a way
around it?
Not quite what is in the the init script in rc.d, have you tried running
the initdb command directly? As you say I believe there are permissions
problems. So following the instructions found below may solve your
problem:
http://www.postgresql.org/**docs/9.2/interactive/app-**initdb.htmlhttp://www.postgresql.org/docs/9.2/interactive/app-initdb.html
-David
--
Adrian Klaver
adrian.kla...@gmail.com
I've tried initdb directly:
initdb -D /zdb/pgsql/data
...and also through pg_ctl:
pg_ctl initdb -D /zdb/pgsql/data
...and still seem to wind up with the error:
creating template1 database in /zdb/pgsql/data/base/1 ... FATAL:
could not open file pg_xlog/**00010001 (log file 0,
segment 1): No such file or directory
You are doing the above as the database user ex:postgres?
The database user has permissions on /zdb/pgsql/data?
-David
--
Adrian Klaver
adrian.kla...@gmail.com
The rc.d script executes the command as the correct user. This is the line
in rc.d script that runs the initdb command:
su -l -c ${postgresql_class} ${postgresql_user} -c exec
/usr/local/bin/initdb ${postgresql_initdb_flags} -D ${postgresql_data}
Not sure about his permission though
Re: [GENERAL] initdb error
On 12/13/2012 08:35 AM, Tom Lane wrote: David Noel david.i.n...@gmail.com writes: I've tried initdb directly: initdb -D /zdb/pgsql/data ...and still seem to wind up with the error: creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory You could get more information by using the --noclean switch to prevent removal of the datadir after failure, and then having a look at the debris. Is there a pg_xlog subdirectory inside /zdb/pgsql/data, and if so what permissions has it got? Perhaps it is not a directory, but a symlink to somewhere else? Always learning, did not know --noclean existed. That is handy. Thanks. regards, tom lane -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On Thu, Dec 13, 2012 at 10:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: David Noel david.i.n...@gmail.com writes: I've tried initdb directly: initdb -D /zdb/pgsql/data ...and still seem to wind up with the error: creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory Hm, that eliminates my first theory that the rc.d script is using initdb's --xlogdir switch to try to put pg_xlog someplace that doesn't exist on your system. But it seems like this must be some variant of that. A simple permissions problem is not very credible, because at this point initdb has successfully made the data directory and a bunch of files within it already. You could get more information by using the --noclean switch to prevent removal of the datadir after failure, and then having a look at the debris. Is there a pg_xlog subdirectory inside /zdb/pgsql/data, and if so what permissions has it got? Perhaps it is not a directory, but a symlink to somewhere else? regards, tom lane Tom rc.d script doesn't seem to be using --xlogdir anywhere. I have uploaded the script here: http://pastebin.com/ahAyZ2tP . Amitabh
Re: [GENERAL] initdb error
You are doing the above as the database user ex:postgres? confirmed: ygg:/usr/home/ygg whoami pgsql The database user has permissions on /zdb/pgsql/data? confirmed: ygg:/usr/home/ygg ll /zdb/ total 3 drwxrwxrwx 3 cvswheel 3 Dec 12 15:33 cvsroot drwxrwxrwx 2 pgsql wheel 2 Dec 13 10:17 pgsql -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: David Noel david.i.n...@gmail.com writes: I've tried initdb directly: initdb -D /zdb/pgsql/data ...and still seem to wind up with the error: creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory Hm, that eliminates my first theory that the rc.d script is using initdb's --xlogdir switch to try to put pg_xlog someplace that doesn't exist on your system. But it seems like this must be some variant of that. A simple permissions problem is not very credible, because at this point initdb has successfully made the data directory and a bunch of files within it already. You could get more information by using the --noclean switch to prevent removal of the datadir after failure, and then having a look at the debris. Is there a pg_xlog subdirectory inside /zdb/pgsql/data, and if so what permissions has it got? Perhaps it is not a directory, but a symlink to somewhere else? regards, tom lane ygg:/usr/home/ygg initdb -D /zdb/pgsql/data --noclean ... creating template1 database in /zdb/pgsql/data/base/1 ... FATAL: could not open file pg_xlog/00010001 (log file 0, segment 1): No such file or directory child process exited with exit code 1 initdb: data directory /zdb/pgsql/data not removed at user's request ygg:/usr/home/ygg ll /zdb/pgsql/ total 2 drwx-- 14 pgsql wheel 18 Dec 13 12:42 data ygg:/usr/home/ygg ll /zdb/pgsql/data/ total 53 -rw--- 1 pgsql wheel 4 Dec 13 12:42 PG_VERSION drwx-- 3 pgsql wheel 3 Dec 13 12:42 base drwx-- 2 pgsql wheel 2 Dec 13 12:42 global drwx-- 2 pgsql wheel 2 Dec 13 12:42 pg_clog -rw--- 1 pgsql wheel 4467 Dec 13 12:42 pg_hba.conf -rw--- 1 pgsql wheel 1636 Dec 13 12:42 pg_ident.conf drwx-- 4 pgsql wheel 4 Dec 13 12:42 pg_multixact drwx-- 2 pgsql wheel 3 Dec 13 12:42 pg_notify drwx-- 2 pgsql wheel 2 Dec 13 12:42 pg_serial drwx-- 2 pgsql wheel 2 Dec 13 12:42 pg_snapshots drwx-- 2 pgsql wheel 2 Dec 13 12:42 pg_stat_tmp drwx-- 2 pgsql wheel 2 Dec 13 12:42 pg_subtrans drwx-- 2 pgsql wheel 2 Dec 13 12:42 pg_tblspc drwx-- 2 pgsql wheel 2 Dec 13 12:42 pg_twophase drwx-- 3 pgsql wheel 3 Dec 13 12:42 pg_xlog -rw--- 1 pgsql wheel 19713 Dec 13 12:42 postgresql.conf ygg:/usr/home/ygg ll /zdb/pgsql/data/pg_xlog/ total 2 drwx-- 2 pgsql wheel 2 Dec 13 12:42 archive_status -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/2012 10:42 AM, David Noel wrote: You are doing the above as the database user ex:postgres? confirmed: ygg:/usr/home/ygg whoami pgsql The database user has permissions on /zdb/pgsql/data? confirmed: ygg:/usr/home/ygg ll /zdb/ total 3 drwxrwxrwx 3 cvswheel 3 Dec 12 15:33 cvsroot drwxrwxrwx 2 pgsql wheel 2 Dec 13 10:17 pgsql Hmmm. Saw the subsequent post also. More questions:( The whoami above shows running from ygg home directory. How did you become pgsql? Does the pgsql user have a login account you could use? Where is /zdb ? -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/2012 10:47 AM, David Noel wrote: On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: ygg:/usr/home/ygg ll /zdb/pgsql/data/pg_xlog/ total 2 drwx-- 2 pgsql wheel 2 Dec 13 12:42 archive_status Different train of thought, away from permissions. How was Postgres installed? Where there any errors during the install process?-- Is there another version of Postgres on this machine? Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/12, Adrian Klaver adrian.kla...@gmail.com wrote: On 12/13/2012 10:47 AM, David Noel wrote: On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: ygg:/usr/home/ygg ll /zdb/pgsql/data/pg_xlog/ total 2 drwx-- 2 pgsql wheel 2 Dec 13 12:42 archive_status Different train of thought, away from permissions. How was Postgres installed? Where there any errors during the install process?-- Is there another version of Postgres on this machine? Adrian Klaver adrian.kla...@gmail.com I'd logged in as ygg via `su ygg`. /zdb is a zfs volume I've created for cvs and postgres. Postgres was installed via `make install` and there were no errors during the install process. I could try deinstalling and installing it again... maybe that will fix something. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
Unfortunately no luck there. Still stick with the same error. On 12/13/12, David Noel david.i.n...@gmail.com wrote: On 12/13/12, Adrian Klaver adrian.kla...@gmail.com wrote: On 12/13/2012 10:47 AM, David Noel wrote: On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: ygg:/usr/home/ygg ll /zdb/pgsql/data/pg_xlog/ total 2 drwx-- 2 pgsql wheel 2 Dec 13 12:42 archive_status Different train of thought, away from permissions. How was Postgres installed? Where there any errors during the install process?-- Is there another version of Postgres on this machine? Adrian Klaver adrian.kla...@gmail.com I'd logged in as ygg via `su ygg`. /zdb is a zfs volume I've created for cvs and postgres. Postgres was installed via `make install` and there were no errors during the install process. I could try deinstalling and installing it again... maybe that will fix something. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
David Noel david.i.n...@gmail.com writes: On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: You could get more information by using the --noclean switch to prevent removal of the datadir after failure, and then having a look at the debris. Is there a pg_xlog subdirectory inside /zdb/pgsql/data, and if so what permissions has it got? Perhaps it is not a directory, but a symlink to somewhere else? [ nothing obviously wrong there... ] Well, it looks like there are no easy answers here, so we'll have to start digging. Is this a purely stock version of Postgres? Which release exactly? Where did you get it from, or if you built it yourself, what configuration options did you use? What's the platform exactly? What I'd suggest as a next step is to use strace or local equivalent on the initdb run, to capture a log of everything it does with pg_xlog. (And everything else too --- the log is likely to be bulky, so please don't post it here. You could send it to me off-list if it makes no sense to you.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
David Noel david.i.n...@gmail.com writes: /zdb is a zfs volume I've created for cvs and postgres. zfs eh? What happens if you point initdb at a non-zfs volume? (Im wondering if zfs has issues with the O_DIRECT flag that we'll probably try to use with pg_xlog files.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: David Noel david.i.n...@gmail.com writes: /zdb is a zfs volume I've created for cvs and postgres. zfs eh? What happens if you point initdb at a non-zfs volume? (Im wondering if zfs has issues with the O_DIRECT flag that we'll probably try to use with pg_xlog files.) I /boot off of a UFS volume so I created a directory there, chown and chmod'ed it, then ran initdb again. Same error, unfortunately. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
David Noel david.i.n...@gmail.com writes: On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: (Im wondering if zfs has issues with the O_DIRECT flag that we'll probably try to use with pg_xlog files.) I /boot off of a UFS volume so I created a directory there, chown and chmod'ed it, then ran initdb again. Same error, unfortunately. Hm. So far as I can find from googling, ZFS doesn't support O_DIRECT, or if it does the support is very new. However, if that were the problem then you ought to be seeing EINVAL or similar, not ENOENT; and what's more the file should have gotten created before we'd try to open it with O_DIRECT, so it should have been there after --noclean. So I'm still baffled. Back to wondering if strace will show anything interesting. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On 12/13/2012 01:40 PM, David Noel wrote: On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: David Noel david.i.n...@gmail.com writes: /zdb is a zfs volume I've created for cvs and postgres. zfs eh? What happens if you point initdb at a non-zfs volume? (Im wondering if zfs has issues with the O_DIRECT flag that we'll probably try to use with pg_xlog files.) I /boot off of a UFS volume so I created a directory there, chown and chmod'ed it, then ran initdb again. Same error, unfortunately. Well this has definitely moved up a support level and past anything I know about. For the record what version of FreeBSD are you running in case someone is searching the archives? -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb error
On Fri, Dec 14, 2012 at 3:10 AM, David Noel david.i.n...@gmail.com wrote: On 12/13/12, Tom Lane t...@sss.pgh.pa.us wrote: David Noel david.i.n...@gmail.com writes: /zdb is a zfs volume I've created for cvs and postgres. zfs eh? What happens if you point initdb at a non-zfs volume? (Im wondering if zfs has issues with the O_DIRECT flag that we'll probably try to use with pg_xlog files.) I /boot off of a UFS volume so I created a directory there, chown and chmod'ed it, then ran initdb again. Same error, unfortunately. David Did you use ports to install postgresql? What is the version of postgresql and freebsd you are using? I am getting a different output while running the initdb command through the rc script, and it's not using the -D path to initialize the cluster, it falls back to the default location /usr/local/pgsql/data . Setting postgresql_data=/usr/local/pgsql1/data in /etc/rc.conf makes it initialize at the right location . I did not had to mess with an permissions and the rc commands were all run as root. The above was tested on FreeBSD 9.1 with Postgresql 9.2 on UFS. On FreeBSD 8.1 with Postgresql 9.1 on UFS installed though ports, it was the same story, except that I had to change ownership to user pgsql for the /usr/local/pgsql1 directory Amitabh
Re: [GENERAL] initdb error: could not identify current directory (or,
% cd /var/data/pgsql still reports the absolute path -- /Volumes/data/pgsql It looks to me like you are attempting to mount a few volumes under /var? I think that's going to wrinkle your handkerchief in Darwin. -- Joel Rees [EMAIL PROTECTED] digitcom, inc. 株式会社デジコム Kobe, Japan +81-78-672-8800 ** http://www.ddcom.co.jp ** ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] initdb error: could not identify current directory
hi joel, It looks to me like you are attempting to mount a few volumes under /var? actually, no. i'm symlinking local volumes mounted where they're supposed to be, in /Volumes, to ny /var/sub-hierarchy. I think that's going to wrinkle your handkerchief in Darwin. it's all been settled, actually (thread's discontinious ... sorry). turns out it was the perms/ownership of the actual mount dir /Volumes/X that were the(my) problem. cheers, richard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SOLVED] Re: [GENERAL] initdb error: could not identify current directory (or, what have i done now?)
OpenMacNews [EMAIL PROTECTED] writes: on my sys: % ls -ald /Volumes/data drwxr-x--x 12 openmac wheel 408 Nov 27 15:25 /Volumes/data/ Ah-hah, yes that's undoubtedly it. if this *does* turn out to be the case, does it make sense to have the script check perms up through the physical/path of the cwd and report with a more specific/desciptive error if they're not at least 555 on the mount point? I'm not in the business of reimplementing getcwd(); especially not to deal with a problem that will break many other things besides Postgres. I'd suggest filing a bug against whatever tool you used to create /Volumes/data/, suggesting that they adopt a less brain-dead default permissions setting. Execute-only on a mount point is just silly. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [SOLVED] Re: [GENERAL] initdb error: could not identify current
hi tom, % ls -ald /Volumes/data drwxr-x--x 12 openmac wheel 408 Nov 27 15:25 /Volumes/data/ Ah-hah, yes that's undoubtedly it. and, since i've cleared that up pgsql is, again, behaving. yay. for posterity's -- and other OSX users' -- sake, that's: for the relevant drives/mounts in /Volumes, you need: perms = 555 (i use) group should include your pgsql unprivileged user 'default' ownership, i believe, is root:admin for mounts, hence your pgsql user would need to be added as a user to grup:admin if this *does* turn out to be the case, does it make sense to have the script check perms up through the physical/path of the cwd and report with a more specific/desciptive error if they're not at least 555 on the mount point? I'm not in the business of reimplementing getcwd(); especially not to deal with a problem that will break many other things besides Postgres. whoa! i wasn't suggesting that at all ... rather, perhaps, simply a perms check from within the initdb script and an 'informative' error to the end-user. if i were the 1st/only to see such an issue, i'd, of course, not even bother with the suggestion ... but, as we've seen, it's raised its ugly head elsewhere (google: 'getcwd initdb') I'd suggest filing a bug against whatever tool you used to create /Volumes/data/, suggesting that they adopt a less brain-dead default permissions setting. Execute-only on a mount point is just silly. i have a suspicion it has to do with my filesharing/automount system/setup/settings. i'd had a bunch o' headaches a fairly long while back w/ getting Samba, AFS NFS to play nice together. i'm fairly sure perms were changed, and the mount points may have been (inadvertently?) munged. why is 'suddenly' changed in the last days, i have no flippin' idea as yet! postgresql may have been, simply, the 1st (me -- surprised) app to 'hit' the getcwd path sensitivity. hence, i think i have to file a bug-report with myself ... =) two points o' feedback: (a) without your help/suggestions, finiding this would've taken me a *lot* longer (thx!), and (b) if this is in the pgsql docs (should it be?), i simply missed, misread or misunderstood it. cheers, richard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SOLVED] Re: [GENERAL] initdb error: could not identify current directory (or, what have i done now?)
OpenMacNews [EMAIL PROTECTED] writes: whoa! i wasn't suggesting that at all ... rather, perhaps, simply a perms check from within the initdb script and an 'informative' error to the end-user. We're doing the best we can already: when the failure occurs, we really don't know which directory is the problem, and cannot find out because we can't navigate above it to find out its name. I note that pwd is not any better: g42:~ tgl$ mkdir ~/zit g42:~/zit tgl$ mkdir ~/zit/zap g42:~/zit tgl$ chmod 111 ~/zit g42:~/zit tgl$ cd ~/zit/zap g42:~/zit/zap tgl$ pwd /Users/tgl/zit/zap g42:~/zit/zap tgl$ /bin/pwd pwd: : Permission denied g42:~/zit/zap tgl$ (bash is probably not doing anyone any favors by masking the problem in its built-in PWD command.) There are limited situations where it makes sense to create a directory that has execute but not read permissions (drop box directories being the main thing I can think of offhand). But it's simply wrong to create a directory that way without a very specific purpose in mind. You need to try to reconstruct how /Volumes/data/ got to be that way, and see if it was simple pilot error or if some tool messed up the permissions for you. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SOLVED] Re: [GENERAL] initdb error: could not identify current
tom, We're doing the best we can already: when the failure occurs, we really don't know which directory is the problem, and cannot find out because we can't navigate above it to find out its name. good point. catch-22. at the very least, some knowledgeable commentary in docs/FAQ/howto/Troubleshooting/etc could well be useful ... I note that pwd is not any better: g42:~ tgl$ mkdir ~/zit g42:~/zit tgl$ mkdir ~/zit/zap g42:~/zit tgl$ chmod 111 ~/zit g42:~/zit tgl$ cd ~/zit/zap g42:~/zit/zap tgl$ pwd /Users/tgl/zit/zap g42:~/zit/zap tgl$ /bin/pwd pwd: : Permission denied g42:~/zit/zap tgl$ interesting. i need to read-up/monkey-around a bit b4 it bites me in the a__ again. (bash is probably not doing anyone any favors by masking the problem in its built-in PWD command.) being primarily a tcsh user (yes, i'm old), i did'na kno that. so *that's* the diff bet pwd and /bin/pwd on _your_ sys, yes? You need to try to reconstruct how /Volumes/data/ got to be that way, and see if it was simple pilot error or if some tool messed up the permissions for you. of course, you're right. i'm betting on occam's razor -- 'pilot error' (hence, the (or, what have i done now?) in the Sub:), but due diligence _is_ called for. (there's a cute/useful mount manager util called SharePoints which i tried a while back that i _think_ may have made it EASY for me to screw things up ... not their fault, tho) again, tom, thanks! now on to make postfix behave w/ pgsql8rc1! =) best, richard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] initdb error: could not identify current directory (or, what have i done now?)
OpenMacNews [EMAIL PROTECTED] writes: su testuser % /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser could not identify current directory: Permission denied What directory are you in when you give this command? (AFAIR su doesn't change directory ... you might be better off with su - testuser ...) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] initdb error: could not identify current directory (or,
hi there, % /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser could not identify current directory: Permission denied What directory are you in when you give this command? (AFAIR su doesn't change directory ... you might be better off with su - testuser ...) h, that's an interesting question. per your suggestion i tried su - testuser, then various combos of su, su -, sudo, etc, etc. -- all to no avail. then, i stumbled across the following behavior.: (1) % rm -rf /var/data/pgsql /Volumes/data/pgsql % ls -ald /var/data/pgsql lrwxr-xr-x 1 root wheel 27 Nov 22 20:26 /var/data/pgsql - /Volumes/data/pgsql % ls -ald /Volumes/data/pgsql drwxrwxr-x 12 testuser testuser 408 Nov 25 09:12 /Volumes/data/pgsql % cd /var/data/pgsql % pwd /Volumes/data/pgsql % sudo -u testuser /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser IT CHOKES. with: could not identify current directory: Permission denied could not identify current directory: Permission denied could not identify current directory: Permission denied The program postgres is needed by initdb but was not found in the same directory as initdb. Check your installation. (2) % rm -rf /var/data/pgsql /Volumes/data/pgsql % ls -ald /var lrwxr-xr-x 1 root admin 11 Nov 23 10:28 /var - private/var % ls -ald /private/var drwxr-xr-x 24 root wheel 816 Dec 3 14:51 /private/var % cd /var % pwd /private/var % sudo -u testuser /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser IT WORKS. % ls -ald /var/data/pgsql drwx-- 12 testuser testuser 408 Dec 3 16:03 /var/data/pgsql % ls /var/data/pgsql PG_VERSION global pg_hba.confpg_subtrans pg_xlog basepg_clog pg_ident.conf pg_tblspcpostgresql.conf now, i'd guess that that indicates a problem with (a) exec.c's getcwd, (b) my understanding of the behavior of 'su' et al ..., and/or (c) perms/ownership *something* doesn't like being *in* a dir owned by testuser:testuser ... fwiw, note also: % niutil -read / /users/testuser name: testuser shell: /bin/tcsh realname: Test User uid: 57 gid: 57 change: 0 expire: 0 _shadow_passwd: generateduid: 9ED08FE5-3755-11D9-8050-0025038BA5BD authentication_authority: ;ShadowHash; passwd: % niutil -read / /groups/testuser name: testuser gid: 57 users: testuser root admin daemon what've i missed? cheers, richard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] initdb error: could not identify current directory (or, what have i done now?)
OpenMacNews [EMAIL PROTECTED] writes: then, i stumbled across the following behavior.: % rm -rf /var/data/pgsql /Volumes/data/pgsql % ls -ald /var/data/pgsql lrwxr-xr-x 1 root wheel 27 Nov 22 20:26 /var/data/pgsql - /Volumes/data/pgsql % ls -ald /Volumes/data/pgsql drwxrwxr-x 12 testuser testuser 408 Nov 25 09:12 /Volumes/data/pgsql Huh? Why didn't the rm -rf remove both of those? Or are you skipping some steps? % cd /var/data/pgsql % pwd /Volumes/data/pgsql This is odd ... when I do pwd I see the path as it was told to cd. I have to say /bin/pwd to get what you're showing. % sudo -u testuser /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser IT CHOKES. Couldn't reproduce this, using fully up-to-date 10.3.6. The man page for getcwd does say that it will fail with EACCES (ie, permission denied) if any component of the path is unreadable. You didn't show us all the steps of the paths /private/var/data and /Volumes/data ... maybe there's a non-world-readable directory involved? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] initdb error: could not identify current directory (or,
hi tom, % ls -ald /Volumes/data/pgsql drwxrwxr-x 12 testuser testuser 408 Nov 25 09:12 /Volumes/data/pgsql Huh? Why didn't the rm -rf remove both of those? Or are you skipping some steps? oops, sorry, copy-n-paste-itis: % rm -rf /var/data/pgsql/* /Volumes/data/pgsql/* % cd /var/data/pgsql % pwd /Volumes/data/pgsql This is odd ... when I do pwd I see the path as it was told to cd. I have to say /bin/pwd to get what you're showing. my pwd is aliased to: alias pwd '/bin/pwd ;\\ set prompt = [EMAIL PROTECTED] ;\\ if (`dirs` == ~) set prompt = [EMAIL PROTECTED] ' checking in my ~/.cshrc, tho', it had -- apparently -- been munged in a copy-n-paste to: alias pwd '/bin/pwd ;\\ set prompt = [EMAIL PROTECTED] ;\\ if (`dirs` == ~) set prompt = [EMAIL PROTECTED] ' so, (a) i corrected the alias % sudo -u testuser /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser -- still WORKS if cd to /var first -- still CHOKES if cd to cd /var/data/pgsql first % cd /var/data/pgsql still reports the absolute path -- /Volumes/data/pgsql (b) i unaliased pwd checking % alias pwd % which pwd /bin/pwd same results h why are you getting different results for 'pwd' and '/bin/pwd' what does YOUR 'which pwd' tell you? Couldn't reproduce this, using fully up-to-date 10.3.6. my gut sez this has GOT to do with my symlinks, etc. ... The man page for getcwd does say that it will fail with EACCES (ie, permission denied) if any component of the path is unreadable. You didn't show us all the steps of the paths /private/var/data and /Volumes/data ... maybe there's a non-world-readable directory involved? methinks you're on to something ... after cd-int to /var, and inidb'ing ... tho' it DOES create the dirs/data, i caught: getcwd: cannot access parent directories: Permission denied so, per reuqest, here are the steps to the path: % unalias pwd % which pwd /bin/pwd % ls -ald /private/var drwxr-xr-x 24 root wheel816 /private/var % ls -ald /var lrwxr-xr-x 1 root admin 11 /var - private/var % ls -ald /var/data lrwxr-xr-x 1 root wheel 27 /var/data - /Volumes/data % ls -ald /var/data/pgsql drwx-- 12 testuser testuser 408 /var/data/pgsql (i) % cd /private/var % pwd /private/var (ii) % cd /var % pwd /private/var (iii) % cd /var/data % pwd /Volumes/data (iv) % cd /var/data/pgsql % pwd /Volumes/data/pgsql those 'pwd' results have me a bit confused ... sumthin's not right. (iii) (iv) are 'pwd's IN a symlinked dir, and result in the full path. (i) is a 'pwd' in an absolute dir, and returns the absolute path BUT, (i) is a pwd IN a symlinked path, yet returns the absolute path, unlike (iii)/(iv) i need to stare some more, and dig a little on getcwd. again, i think pwd's, and perhaps getcwd's, behavior in _my_ symlinked dirs/path + perms scenario may be the culprit ... thoughts? richard ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] initdb error: could not identify current directory (or,
hi tom, per this thread, i've been googl'ing on 'getcwd initdb permissions parent' and find lots of refs ... issues with folks having 'permission denied' errors if parent directories don't have correct permissions, etc. this 'smells' pretty much like the issue at hand here ... tho' i dunno (yet) what permissions i don't have set correctly. i think the symlinked directories have confused matters -- well, at least they've confused me. i'm going slightly cross-eyed tonite; will check further in the morning ... if you have any further insight as to where the issue is, ple let me know ... otherwise, i think it may be time to drop back to all local/absolute dirs and start iterating through changes ... cheers again thx! for all your help! richard ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[SOLVED] Re: [GENERAL] initdb error: could not identify current directory (or, what have i done now?)
hi tom, i think i got it ... keeping in mind your question re: read perms, reading this thread: http://groups.google.com/groups?hl=enlr=threadm=60b4un%24cqh%241%40dolphin.neosoft.comrnum=2prev=/groups%3Fq%3Dgetcwd%2520permissions%2520symlink%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg and noting there suspicion would be that one of your mointpoints (like /usr) has mangled permissions, it seems it's the mount point in the path of the relevant symlink that needs the right perms. for me that's, e.g., /Volumes/data tho' i'd reported: % ls -ald /var/data lrwxr-xr-x 1 root wheel 27 /var/data - /Volumes/data its actually (apparently) the perms on the absolute dir path /Volumes/data that matter ... to getcwd. on my sys: % ls -ald /Volumes/data drwxr-x--x 12 openmac wheel 408 Nov 27 15:25 /Volumes/data/ the thread (above) mentioned changing perms to at least 555 on the mount point, so i: % chmod 755 /Volumes/data % ls -ald /Volumes/data drwxrwxr-x 12 openmac wheel 408 Nov 27 15:25 /Volumes/data/ and tried initdb again. so far (!) it seems to run fine without the getced 'persmission denied' errors from any directory. i'll test this some more in the morn, and make sure i'm not deluding myself ... if this *does* turn out to be the case, does it make sense to have the script check perms up through the physical/path of the cwd and report with a more specific/desciptive error if they're not at least 555 on the mount point? thx g'nite. richard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[GENERAL] initdb error-ld-elf.so.1: Shared object libpq.so.2 not found
Greetings ! I got the above error [see subject] when I attempted to "initdb". What's wrong and how do I fix it ? Appreciatively, Courtney
Re: [GENERAL] initdb error-ld-elf.so.1: Shared object libpq.so.2 not found^H
I got the above error [see subject] when I attempted to "initdb". What's wrong and how do I fix it ? what operating system? -- [ Jim Mercer [EMAIL PROTECTED] +1 416 506-0654 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
Re: [GENERAL] initdb error-ld-elf.so.1: Shared object libpq.so.2 not found^H
Jim Mercer wrote: I got the above error [see subject] when I attempted to "initdb". What's wrong and how do I fix it ? what operating system? -- [ Jim Mercer [EMAIL PROTECTED] +1 416 506-0654 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ] _ Sorry 'bout that. FreeBSD3.3. Gratefully, Courtney
Re: [GENERAL] initdb error-ld-elf.so.1: Shared object libpq.so.2 not found^H
Jim Mercer wrote: I got the above error [see subject] when I attempted to "initdb". What's wrong and how do I fix it ? what operating system? -- [ Jim Mercer [EMAIL PROTECTED] +1 416 506-0654 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ] Jim, A couple of other things that might shed light: 1-I am logged in as user "postgres" 2-libpq.so.2 is in /usr/local/pgsql/lib; and is also linked to by libpq.so in said dir 3-owner/group are both "postgres" [of libpq.so.2, as well as all the other files in said dir] Thanks again, Courtney
