Thread: 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
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 filesWhen 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?thanksRichard
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
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@postgresql.org [mailto:pgsql-cygwin-owner@postgresql.org]On Behalf Of Frank Seesink Sent: Sunday, September 21, 2003 8:18 PM To: pgsql-cygwin@postgresql.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@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 ---------------------------(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 Pierre, The following change breaks proftpd: http://cygwin.com/ml/cygwin-cvs/2003-q3/msg00237.html By "breaks", I mean the following failure occurs when a user attempts to authenticate: C:\Cygwin\usr\sbin\proftpd.exe: *** CreateFileMapping, Win32 error 5. Terminating. I was able to workaround and isolate the problem with the attached "patch" -- that is reverting to the old behavior. Any ideas on how to fix the problem correctly? 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
Attachment
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