Re: FATAL: lock file "postmaster.pid" already exists

From: deepak <deepak(dot)pn(at)gmail(dot)com>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: FATAL: lock file "postmaster.pid" already exists
Date: 2012-05-08 16:13:22
Message-ID: CAALYutc0LucvgSRxYW44Z1XsAEohxsr1VffO_rf9gXsUWtOa6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, May 8, 2012 at 3:09 AM, Alban Hertroys <haramrae(at)gmail(dot)com> wrote:

> On 8 May 2012, at 24:34, deepak wrote:
>
> > Hi,
> >
> > On Windows 2008, sometimes the server fails to start due to an existing
> "postmaster.pid' file.
> >
> > I tried rebooting a few times and even force shutting down the server,
> and it started up fine.
> > It seems to be a race-condition of sorts in the code that detects
> whether the process with PID
> > in the file is running or not.
>
> No, it means that postgres wasn't shut down properly when Windows shut
> down. Removing the pid-file is one of the last things the shut-down
> procedure does. The file is used to prevent 2 instances of the same server
> running on the same data-directory.
>
> If it's a race-condition, it's probably one in Microsoft's shutdown code.
> I've seen similar problems with Outlook mailboxes on a network directory;
> Windows unmounts the remote file-systems before Outlook finished updating
> its files under that mount point, so Outlook throws an error message and
> Windows doesn't shut down because of that.
>
> I don't suppose that pid-file is on a remote file-system?
>
> No, it's local.

> > Does any one have this same problem? Any way to fix it besides removing
> the PID file
> > manually each time the server complains about this?
>
>
> You could probably script removal of the pid file if its creation date is
> before the time the system started booting up.
>
>
Thanks, it looks like the code already seems to overwrite an old pid file
if no other process is using it (if I understand the code correctly, it
just echoes a byte onto a pipe to detect this).

Still, I can't see under what conditions this occurs, but I have seen it
happen a couple of times, just that I don't know how to predictably
reproduce the problem.

--
Deepak

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rebecca Clarke 2012-05-08 16:16:44 Re: .pgpass not working
Previous Message Raymond O'Donnell 2012-05-08 16:00:39 Re: connect local pgAdmin III to remote postgres server