Re: Leftover PID files - Mailing list pgsql-cygwin

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@postgresql.org
>     [mailto:pgsql-cygwin-owner@postgresql.org]*On Behalf Of *Richard
>     Sydney-Smith
>     *Sent:* Tuesday, September 16, 2003 11:55 PM
>     *To:* pgsql-cygwin@postgresql.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