Re: Leftover PID files

When the system restarts after being incorectly shut down a PID file is left in the data directory which will stop the service re-starting.

How do you get the operating system to delete this file before attempting to restart the service?

thanks

Richard

You basically need a command file to run at boot time. There are many ways
to do this. For example, I'm under WinXP, so I downloaded cygwin's init
module (which emulates system V init) and added the following to the /etc/rc
file that init runs at startup:

# Delete postgres sockets
chmod 777 /tmp/.s.PGSQL.*
rm -f /tmp/.s.PGSQL.*
# Delete Postgres PID file
chmod 777 /usr/share/postgresql/data/postmaster.pid
rm -f /usr/share/postgresql/data/postmaster.pid
-----Original Message-----
From: pgsql-cygwin-owner(at)postgresql(dot)org
[mailto:pgsql-cygwin-owner(at)postgresql(dot)org]On Behalf Of Richard Sydney-Smith
Sent: Tuesday, September 16, 2003 11:55 PM
To: pgsql-cygwin(at)postgresql(dot)org
Subject: [CYGWIN] Leftover PID files

When the system restarts after being incorectly shut down a PID file is
left in the data directory which will stop the service re-starting.

How do you get the operating system to delete this file before attempting
to restart the service?

thanks

Richard

Ah, but how do you start PostgreSQL, Rubin? If you're using cygrunsrv
as in Jason Tishler's instructions, and you have the postmaster service
config'd to 'Automatic', you may well get burned by this, unless things
have changed in the past few months.

If you do things "the Unix way", then fine. That implies you also fire
up postmaster via such scripts. But if you use cygrunsrv, you're now in
Windows NT world, where the order of services firing up can bite you due
to the unpredictability of it all, and last I looked, init doesn't
necessarily beat out Windows firing up the postmaster service. (Has
this changed?)

The real question is, what EXACTLY are you looking to do, Richard? Are
you looking for a brute force approach where ANY time you fire up
postmaster, you want any existing PID files deleted? As I'm sure you
know, this is A Bad Idea (TM), as the whole point of the PID file is to
prevent multiple instances of postmaster from running (and also to give
you a heads up when PostgreSQL barfed unexpectedly). PostgreSQL checks
for a PID on startup to see if another copy of itself is already
running. If so, it shuts down to prevent possible data corruption (two
postmasters going after same data store...not good). This kind of
defeats that.

But it looks like you're after the same thing I was, though now
hopefully for different reasons. When I started running PostgreSQL as
an NT service, I found that if I shutdown Windows, due to a bug in
Cygwin, PostgreSQL was not given enough time to shutdown properly,
leaving behind a PID file on restart/startup. This, of course,
prevented PostgreSQL from starting on bootup.

[SIDE NOTE: Jason Tishler, in your email from 12 June 2003:
http://article.gmane.org/gmane.comp.db.postgresql.cygwin/1283

You mentioned this was fixed in CVS and would be in Cygwin 1.5.x. That
still the case? Should the issue of lingering PID files on system
reboot be a by-gone? I haven't checked recently as I had my own
scripting solution in place for awhile and it's worked like a champ for
me. And to be honest I've been off-list awhile so forgive the ignorance
if this was covered between then and now.]

Basically, Richard, if your goal is to

1. run PostgreSQL as a Windows NT service
2. have PostgreSQL config'd 'Automatic' so it fires up on startup, AND
3. your intention is to delete any leftover PIDs ONLY on system startup

then what you need is some way to delete such PID files where you can be
sure that deletion occurs BEFORE the postmaster service starts. This
can be tricky, as Windows does not appear to have a nice mechanism like
Unix's inittab files and such. I went through this dance on this list
back in May.

But I did find a solution way back when, using the dependency feature in
NT services. That is, I happen to already have a handy little program
called FireDaemon (www.firedaemon.com), which can 'convert' any
applicatoin into an NT service. I then created such a 'service', which
was really nothing more than launching a .BATch file. This .BATch file
looked for and deleted the postmaster.pid file among other things. I
set this .BATch service to 'Automatic' so it would run on system startup.

But this is not enough. It is critical that the postmaster service is
marked as being 'dependent' upon this .BATch service, to guarantee the
.BATch file runs BEFORE PostgreSQL fires up. You can do this by
removing your current postmaster service with

$ cygrunsrv --remove postmaster

then reinstalling it as listed in the README, adding a second --dep flag
and making postmaster depend on this .BATch service. For example, if
you create a service called 'pgsql-startup', the command might be

$ cygrunsrv --install postmaster --path /usr/bin/postmaster --args "-D
/usr/share/postgresql/data -i" --dep ipc-daemon2 --dep pgsql-startup
--termsig INT --user postgres --shutdown

However, there's yet one more thing I had to do. I had to configure
FireDaemon NOT to do anything once the .BATch file had run. That is, if
you look on my box, the pgsql-startup service is still shown as
'running', even though the .BATch file completed right at bootup time.
This is so the postmaster service will fire up, since it is 'dependent'
on the pgsql-startup service "running" before it starts.

If I haven't fried your brain yet, then note you do not necessarily need
to get FireDaemon (though it's well worth the $25 for what I've used it
for). You may be able to achieve the same functionality using cygrunsrv
itself to install such a batch/script service. And there's also the
srvany.exe utility found in the Windows Resource Kit if you have that.
But you'll need to make sure that the service runs and that, even though
the batch/script has finished, the service does NOT shutdown. This is
key for this approach.

Note the real problem here isn't PostgreSQL, but rather Windows. This
OS family simply does not have the level of granular control those who
use any form of Unix are used to. Good/bad? I'll leave that for
flamebait. :-)

Seth Rubin wrote:

> You basically need a command file to run at boot time. There are many
> ways to do this. For example, I'm under WinXP, so I downloaded cygwin's
> init module (which emulates system V init) and added the following to
> the /etc/rc file that init runs at startup:
>
> # Delete postgres sockets
> chmod 777 /tmp/.s.PGSQL.*
> rm -f /tmp/.s.PGSQL.*
> # Delete Postgres PID file
> chmod 777 /usr/share/postgresql/data/postmaster.pid
> rm -f /usr/share/postgresql/data/postmaster.pid
>
> -----Original Message-----
> *From:* pgsql-cygwin-owner(at)postgresql(dot)org
> [mailto:pgsql-cygwin-owner(at)postgresql(dot)org]*On Behalf Of *Richard
> Sydney-Smith
> *Sent:* Tuesday, September 16, 2003 11:55 PM
> *To:* pgsql-cygwin(at)postgresql(dot)org
> *Subject:* [CYGWIN] Leftover PID files
>
> When the system restarts after being incorectly shut down a PID file
> is left in the data directory which will stop the service re-starting.
>
> How do you get the operating system to delete this file before
> attempting to restart the service?
>
> thanks
>
> Richard

Thanks, Frank. That jogged my memory. I think my NT startup was starting
ipc-daemon after postmaster, which was why I was sometimes having to restart
postmaster after booting. Your email reminded me of what I did last time.

I did the following. First, Only postmaster gets an automatic startup -
ipc-daemon2 and init get "manual" startup. Then you set postmaster to
depend on ipc-daemon2. Lastly set ipc-daemon2 dependent on init. With this
setup in place, it looks like my XP system starts init (which cleans up any
temp files), then ipc-daemon2, then postmaster. I try psql right after
bootup and its working fine. Keeping my fingers crossed...

-- Seth

-----Original Message-----
From: pgsql-cygwin-owner(at)postgresql(dot)org
[mailto:pgsql-cygwin-owner(at)postgresql(dot)org]On Behalf Of Frank Seesink
Sent: Sunday, September 21, 2003 8:18 PM
To: pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [CYGWIN] Leftover PID files

Ah, but how do you start PostgreSQL, Rubin? If you're using cygrunsrv
as in Jason Tishler's instructions, and you have the postmaster service
config'd to 'Automatic', you may well get burned by this, unless things
have changed in the past few months.

If you do things "the Unix way", then fine. That implies you also fire
up postmaster via such scripts. But if you use cygrunsrv, you're now in
Windows NT world, where the order of services firing up can bite you due
to the unpredictability of it all, and last I looked, init doesn't
necessarily beat out Windows firing up the postmaster service. (Has
this changed?)

The real question is, what EXACTLY are you looking to do, Richard? Are
you looking for a brute force approach where ANY time you fire up
postmaster, you want any existing PID files deleted? As I'm sure you
know, this is A Bad Idea (TM), as the whole point of the PID file is to
prevent multiple instances of postmaster from running (and also to give
you a heads up when PostgreSQL barfed unexpectedly). PostgreSQL checks
for a PID on startup to see if another copy of itself is already
running. If so, it shuts down to prevent possible data corruption (two
postmasters going after same data store...not good). This kind of
defeats that.

But it looks like you're after the same thing I was, though now
hopefully for different reasons. When I started running PostgreSQL as
an NT service, I found that if I shutdown Windows, due to a bug in
Cygwin, PostgreSQL was not given enough time to shutdown properly,
leaving behind a PID file on restart/startup. This, of course,
prevented PostgreSQL from starting on bootup.

[SIDE NOTE: Jason Tishler, in your email from 12 June 2003:
http://article.gmane.org/gmane.comp.db.postgresql.cygwin/1283

You mentioned this was fixed in CVS and would be in Cygwin 1.5.x. That
still the case? Should the issue of lingering PID files on system
reboot be a by-gone? I haven't checked recently as I had my own
scripting solution in place for awhile and it's worked like a champ for
me. And to be honest I've been off-list awhile so forgive the ignorance
if this was covered between then and now.]

Basically, Richard, if your goal is to

1. run PostgreSQL as a Windows NT service
2. have PostgreSQL config'd 'Automatic' so it fires up on startup, AND
3. your intention is to delete any leftover PIDs ONLY on system startup

then what you need is some way to delete such PID files where you can be
sure that deletion occurs BEFORE the postmaster service starts. This
can be tricky, as Windows does not appear to have a nice mechanism like
Unix's inittab files and such. I went through this dance on this list
back in May.

But I did find a solution way back when, using the dependency feature in
NT services. That is, I happen to already have a handy little program
called FireDaemon (www.firedaemon.com), which can 'convert' any
applicatoin into an NT service. I then created such a 'service', which
was really nothing more than launching a .BATch file. This .BATch file
looked for and deleted the postmaster.pid file among other things. I
set this .BATch service to 'Automatic' so it would run on system startup.

But this is not enough. It is critical that the postmaster service is
marked as being 'dependent' upon this .BATch service, to guarantee the
.BATch file runs BEFORE PostgreSQL fires up. You can do this by
removing your current postmaster service with

$ cygrunsrv --remove postmaster

then reinstalling it as listed in the README, adding a second --dep flag
and making postmaster depend on this .BATch service. For example, if
you create a service called 'pgsql-startup', the command might be

$ cygrunsrv --install postmaster --path /usr/bin/postmaster --args "-D
/usr/share/postgresql/data -i" --dep ipc-daemon2 --dep pgsql-startup
--termsig INT --user postgres --shutdown

However, there's yet one more thing I had to do. I had to configure
FireDaemon NOT to do anything once the .BATch file had run. That is, if
you look on my box, the pgsql-startup service is still shown as
'running', even though the .BATch file completed right at bootup time.
This is so the postmaster service will fire up, since it is 'dependent'
on the pgsql-startup service "running" before it starts.

If I haven't fried your brain yet, then note you do not necessarily need
to get FireDaemon (though it's well worth the $25 for what I've used it
for). You may be able to achieve the same functionality using cygrunsrv
itself to install such a batch/script service. And there's also the
srvany.exe utility found in the Windows Resource Kit if you have that.
But you'll need to make sure that the service runs and that, even though
the batch/script has finished, the service does NOT shutdown. This is
key for this approach.

Note the real problem here isn't PostgreSQL, but rather Windows. This
OS family simply does not have the level of granular control those who
use any form of Unix are used to. Good/bad? I'll leave that for
flamebait. :-)

Seth Rubin wrote:

> You basically need a command file to run at boot time. There are many
> ways to do this. For example, I'm under WinXP, so I downloaded cygwin's
> init module (which emulates system V init) and added the following to
> the /etc/rc file that init runs at startup:
>
> # Delete postgres sockets
> chmod 777 /tmp/.s.PGSQL.*
> rm -f /tmp/.s.PGSQL.*
> # Delete Postgres PID file
> chmod 777 /usr/share/postgresql/data/postmaster.pid
> rm -f /usr/share/postgresql/data/postmaster.pid
>
> -----Original Message-----
> *From:* pgsql-cygwin-owner(at)postgresql(dot)org
> [mailto:pgsql-cygwin-owner(at)postgresql(dot)org]*On Behalf Of *Richard
> Sydney-Smith
> *Sent:* Tuesday, September 16, 2003 11:55 PM
> *To:* pgsql-cygwin(at)postgresql(dot)org
> *Subject:* [CYGWIN] Leftover PID files
>
> When the system restarts after being incorectly shut down a PID file
> is left in the data directory which will stop the service re-starting.
>
> How do you get the operating system to delete this file before
> attempting to restart the service?
>
> thanks
>
> Richard

---------------------------(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

Frank,

On Sun, Sep 21, 2003 at 08:18:26PM -0400, Frank Seesink wrote:
> [SIDE NOTE: Jason Tishler, in your email from 12 June 2003:
> http://article.gmane.org/gmane.comp.db.postgresql.cygwin/1283
>
> You mentioned this was fixed in CVS and would be in Cygwin 1.5.x. That
> still the case?

AFAICT, yes, by reading the code. However, I have not tested this
functionality recently.

> Should the issue of lingering PID files on system reboot be a by-gone?

Yes, by this issue. Maybe there is another one lurking?

> And to be honest I've been off-list awhile so forgive the ignorance if
> this was covered between then and now.]

Welcome back -- the list has been too quiet lately. :,)

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
> Frank,
>
> On Sun, Sep 21, 2003 at 08:18:26PM -0400, Frank Seesink wrote:
>
>>[SIDE NOTE: Jason Tishler, in your email from 12 June 2003:
>> http://article.gmane.org/gmane.comp.db.postgresql.cygwin/1283
>>
>>You mentioned this was fixed in CVS and would be in Cygwin 1.5.x. That
>>still the case?
>
>
> AFAICT, yes, by reading the code. However, I have not tested this
> functionality recently.
>
>
>>Should the issue of lingering PID files on system reboot be a by-gone?
>
>
> Yes, by this issue. Maybe there is another one lurking?

Well, can't speak for any new ones. Just did some testing on my
desktop (i.e., my 'test' environment :-) ), and seems PostgreSQL is now
getting enough time to shutdown when I restart Windows. No leftover PID
file. And yes, I disabled my startup service that deletes those for
this test.

And /var/log/postmaster.log shows

LOG: fast shutdown request
LOG: shutting down
LOG: database system is shut down

Not sure if a fast shutdown implies anything, but that last message and
the fact no PID file exists on restart makes me think PostgreSQL has
more time to shutdown now. Not sure if this is due to Windows, Cygwin,
various other changes in my system (we switched antivirus products a few
months back, for example, and file access times have improved), blah blah.

Speaking of which, one thing I DID find was that, upon restart, I found
that the CygIPC (ipc-daemon2) files in /tmp were left behind.
ipc-daemon2 is supposed to clean up after itself when it shuts down (and
it does when I manually shut it down). Possibly the issue of not
shutting down properly on a Windows shutdown/restart has migrated? :-)

Anyway, I still plan to have a cleanup script run at system startup, to
deal with any BSODs or other anomalies. But for what it's worth, things
seem to be better now than before.

>>And to be honest I've been off-list awhile so forgive the ignorance if
>>this was covered between then and now.]
>
> Welcome back -- the list has been too quiet lately. :,)

Thanks! Good to be back. Between travel/vacation, work, and my latest
pet project (getting Jabber server to run completely under Cygwin as it
does under *nix), kinda ran out of hours in the day. :-) Now I'm back
to integrating various things under Windows--Apache, PHPWiki, RADIUS
server, and now this Jabber server--with PostgreSQL. So trying to get
caught up. Amazing all you can do with PostgreSQL. ;-)

Frank,

On Mon, Sep 22, 2003 at 03:18:59PM -0400, Frank Seesink wrote:
> And /var/log/postmaster.log shows
>
> LOG: fast shutdown request
> LOG: shutting down
> LOG: database system is shut down
>
> Not sure if a fast shutdown implies anything, ...

Yes, because there is no "smart shutdown" in the log, we are good to go.

> Speaking of which, one thing I DID find was that, upon restart, I
> found that the CygIPC (ipc-daemon2) files in /tmp were left behind.
> ipc-daemon2 is supposed to clean up after itself when it shuts down
> (and it does when I manually shut it down). Possibly the issue of not
> shutting down properly on a Windows shutdown/restart has migrated? :-)

If the above is truly the case (I have not tested this), then I would
post this issue to the Cygwin mailing list.

Thanks,
Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason Tishler wrote:
> Frank,
>
> On Mon, Sep 22, 2003 at 03:18:59PM -0400, Frank Seesink wrote:
>
>>And /var/log/postmaster.log shows
>>
>> LOG: fast shutdown request
>> LOG: shutting down
>> LOG: database system is shut down
>>
>>Not sure if a fast shutdown implies anything, ...
>
>
> Yes, because there is no "smart shutdown" in the log, we are good to go.
>
>
>>Speaking of which, one thing I DID find was that, upon restart, I
>>found that the CygIPC (ipc-daemon2) files in /tmp were left behind.
>>ipc-daemon2 is supposed to clean up after itself when it shuts down
>>(and it does when I manually shut it down). Possibly the issue of not
>>shutting down properly on a Windows shutdown/restart has migrated? :-)
>
>
> If the above is truly the case (I have not tested this), then I would
> post this issue to the Cygwin mailing list.
>
> Thanks,
> Jason

Jason,

I've now tested on two PCs running Windows XP Pro SP1 (one desktip PIII
866, one IBM ThinkPad T21). Tried this with Cygwin 1.5.4-1, and just
yesterday with 1.5.5-1. From cygcheck,

Package Version Status
cygipc 2.01-2 OK
cygwin 1.5.5-1 OK
postgresql 7.3.4-2 OK

In both cases, PostgreSQL shuts down fine (same log entries as above)
and removes its PID file, but the CygIPC files are left behind after a
restart.

I'm afraid I'm not on the Cygwin mailing list at this point. Any chance
you could cross-post for me?

Frank,

On Tue, Sep 23, 2003 at 09:37:33PM -0400, Frank Seesink wrote:
> In both cases, PostgreSQL shuts down fine (same log entries as above)
> and removes its PID file, but the CygIPC files are left behind after a
> restart.
>
> I'm afraid I'm not on the Cygwin mailing list at this point. Any
> chance you could cross-post for me?

OK, will do.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

This is a new one:

I've got cygwin/postgresql installed on a Spanish Win2K server platform.
All is running fine except if I try to open cygwin with the postgres user
account. All I get is this message:

*** CreateFileMapping, Win32 error 161. Terminating.

I can log on with any other account. I've found absolutely nothing related
to this, and I can't figure it out...something to do with bad permissions or
path info? I incorrectly created the postgres user account the first time,
when I forgot to substitute the password in the following command, and
accidentally ran the mkpasswd command as follows:

net user postgres $password /add /fullname:postgres
/comment:'PostgreSQL user account' /homedir:"$(cygpath -w /home/postgres)"

mkpasswd -l -u postgres >>/etc/passwd

I'm thinking there's some problem related to that mistake...how can I
reverse anything I did related to the postgres account without fully
reinstalling Cygwin/PosgreSQL?

Thanks
Mike

Mike,

On Wed, Sep 24, 2003 at 04:36:24PM -0400, Mike Leahy wrote:
> This is a new one:
>
> I've got cygwin/postgresql installed on a Spanish Win2K server platform.
> All is running fine except if I try to open cygwin with the postgres user
> account. All I get is this message:
>
> *** CreateFileMapping, Win32 error 161. Terminating.

The above *may* be related to a similar problem that I found with
proftpd and recent Cygwin versions. See attached for the details.

What Cygwin version are you running?

$ uname -a

What does the following indicate?

$ net user postgres | fgrep Group

My suggestion is to post to the Cygwin list -- you will get more
traction there.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Frank,

On Wed, Sep 24, 2003 at 10:34:38AM -0400, Jason Tishler wrote:
> On Tue, Sep 23, 2003 at 09:37:33PM -0400, Frank Seesink wrote:
> > In both cases, PostgreSQL shuts down fine (same log entries as
> > above) and removes its PID file, but the CygIPC files are left
> > behind after a restart.
> >
> > I'm afraid I'm not on the Cygwin mailing list at this point. Any
> > chance you could cross-post for me?
>
> OK, will do.

See the following:

http://cygwin.com/ml/cygwin/2003-10/msg00024.html

Sorry for the delay, but as the saying goes:

A patch in hand is worth two in the bush. :,)

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6