Re: Unhelpful initdb error message

On Tuesday, March 06, 2012 7:46:37 am Thom Brown wrote:
> Hi all,
>
> After building Postgres and trying an initdb, I'm getting the following:
>
>
> thom(at)swift:~/Development$ initdb
> The files belonging to this database system will be owned by user "thom".
> This user must also own the server process.
>
> The database cluster will be initialized with locale en_GB.UTF-8.
> The default database encoding has accordingly been set to UTF8.
> The default text search configuration will be set to "english".
>
> fixing permissions on existing directory /home/thom/Development/data ... ok
> creating subdirectories ... ok
> selecting default max_connections ... 10
> selecting default shared_buffers ... 400kB
> creating configuration files ... ok
> creating template1 database in /home/thom/Development/data/base/1 ...
> FATAL: could not remove old lock file "postmaster.pid": No such file
> or directory
> HINT: The file seems accidentally left over, but it could not be
> removed. Please remove the file by hand and try again.
> child process exited with exit code 1
> initdb: removing contents of data directory "/home/thom/Development/data"
>
>
> It can't remove an old lock file due to it not existing, but the hint
> says it was left over but couldn't be removed. The hint contradicts
> the error message. There is nothing in the data directory at all
> before trying this, and nothing after. Repeating initdb yields the
> same result.
>
> But, if I rename the data directory to something else and mkdir data
> again, all is well. I can make it break again by removing the new
> data directory and renaming the old one back to data, still completely
> empty. Note that throughout all of this, Postgres is running, but as
> a separate user and using completely separate directories, since it's
> the standard packaged version on Debian.
>
> Can anyone suggest what is wrong here?

The postmaster.pid is located outside the data directory, but points back to the
data directory. Not sure where Debian, though at a guess somewhere in /var.
Any way search for postmaster.pid.

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com