Thread: Re: PostgreSQL 7.3.2 running as NT service under Windows XP
Frank,
Sorry for the sluggish response time...
On Sat, May 24, 2003 at 12:07:10AM +0200, Frank Seesink wrote:
> Jason Tishler wrote:
> > Most likely yes.
> Now the big $64K question: Why? :-)
Looking at the following Cygwin DLL code:
static BOOL WINAPI
ctrl_c_handler (DWORD type)
{
if (type == CTRL_LOGOFF_EVENT)
return TRUE;
/* Return FALSE to prevent an "End task" dialog box from appearing
for each Cygwin process window that's open when the computer
is shut down or console window is closed. */
***>if (type == CTRL_SHUTDOWN_EVENT)
***> {
***> sig_send (NULL, SIGTERM);
***> return FALSE;
***> }
if (type == CTRL_CLOSE_EVENT)
{
sig_send (NULL, SIGHUP);
return FALSE;
}
...
}
I'm concerned that the Cygwin DLL is actually sending a SIGTERM to the
postmaster even though cygrunsrv is going to send a SIGINT too. Does
the postmaster log indicate a "smart shutdown" or "fast shutdown" when
the pid file is not deleted?
> > Why not wrap postmaster in a shell script,
> > /usr/local/bin/postmaster.sh?
> >
> > #!/bin/sh
> > rm -f /usr/share/postgresql/data/postmaster.pid
> > /usr/bin/postmaster $*
> >
> > And then install postmaster.sh as the "service".
>
> Uh...I think this would fall under the category of "BAD Idea",
> wouldn't it? I mean, the whole point of postmaster.pid is to prevent
> MULTIPLE copies of postmaster from firing up against the same data
> set. All I want to do is make sure no such file exists on startup,
> and ONLY on startup. The above defeats the purpose by deleting it
> regardless.
I would call the above "quick and dirty". I wasn't clear but I assumed
the following:
1. It would only be invoked via net start which will prevent
multiple instances.
2. The script was a starting point *not* the the final version.
One could add something like the following check:
pg_ctl -D /usr/share/postgresql/data status
if [ $? -eq 0 ]
then
exit 1
fi
...
> > I can only recommend checking the log file. Even without the
> > timestamps, you should be able to figure out if PostgreSQL shut and
> > started up cleanly. You can always start with a fresh log file to
> > facilitate the analysis.
>
> I've done that. Still not much use. PostgreSQL isn't very verbose in
> its logging.
Did you add "-d 5" to the postmaster options? Maybe this will give you
a better idea of how far postmaster is getting in its shutdown process.
Another option is the hack postmaster to log with timestamps...
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:
...
>>Now the big $64K question: Why? :-)
>
>
> Looking at the following Cygwin DLL code:
>
> static BOOL WINAPI
> ctrl_c_handler (DWORD type)
> {
> if (type == CTRL_LOGOFF_EVENT)
> return TRUE;
>
> /* Return FALSE to prevent an "End task" dialog box from appearing
> for each Cygwin process window that's open when the computer
> is shut down or console window is closed. */
> ***>if (type == CTRL_SHUTDOWN_EVENT)
> ***> {
> ***> sig_send (NULL, SIGTERM);
> ***> return FALSE;
> ***> }
> if (type == CTRL_CLOSE_EVENT)
> {
> sig_send (NULL, SIGHUP);
> return FALSE;
> }
> ...
> }
>
> I'm concerned that the Cygwin DLL is actually sending a SIGTERM to the
> postmaster even though cygrunsrv is going to send a SIGINT too. Does
> the postmaster log indicate a "smart shutdown" or "fast shutdown" when
> the pid file is not deleted?
I did the following:
* PostgreSQL was running
* I deleted /var/log/postmaster.log
* manually shutdown/restarted PostgreSQL using 'net stop postmaster' and
'net start postmaster' to generate the first few entries
* then rebooted.
The following is the contents of /var/log/postmaster.log:
____________________________________________________________
LOG: database system was shut down at 2003-05-28 16:14:19 EDT
LOG: checkpoint record is at 0/C782D8
LOG: redo record is at 0/C782D8; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 9882; next oid: 20212
LOG: database system is ready
LOG: smart shutdown request
LOG: shutting down
LOG: fast shutdown request
LOG: database system is shut down
LOG: database system was shut down at 2003-05-28 17:57:51 EDT
LOG: checkpoint record is at 0/C78318
LOG: redo record is at 0/C78318; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 9882; next oid: 20212
LOG: database system is ready
____________________________________________________________
From the above, it appears that PostgreSQL first receives a "smart
shutdown request", followed by a "fast shutdown request". Are we
getting closer? :-)
>>>Why not wrap postmaster in a shell script,
>>>/usr/local/bin/postmaster.sh?
>>>
>>> #!/bin/sh
>>> rm -f /usr/share/postgresql/data/postmaster.pid
>>> /usr/bin/postmaster $*
>>>
>>>And then install postmaster.sh as the "service".
>>
>>Uh...I think this would fall under the category of "BAD Idea",
>>wouldn't it? I mean, the whole point of postmaster.pid is to prevent
>>MULTIPLE copies of postmaster from firing up against the same data
>>set. All I want to do is make sure no such file exists on startup,
>>and ONLY on startup. The above defeats the purpose by deleting it
>>regardless.
>
>
> I would call the above "quick and dirty". I wasn't clear but I assumed
> the following:
>
> 1. It would only be invoked via net start which will prevent
> multiple instances.
Actually, I understand what you mean, but technically, no this is not
true. If I do a 'net start postmaster' from the command line when a
copy is already running, this script will delete postmaster.pid and fire
up a 2nd copy.
> 2. The script was a starting point *not* the the final version.
> One could add something like the following check:
>
> pg_ctl -D /usr/share/postgresql/data status
> if [ $? -eq 0 ]
> then
> exit 1
> fi
> ...
This would help.
>>>I can only recommend checking the log file. Even without the
>>>timestamps, you should be able to figure out if PostgreSQL shut and
>>>started up cleanly. You can always start with a fresh log file to
>>>facilitate the analysis.
>>
>>I've done that. Still not much use. PostgreSQL isn't very verbose in
>>its logging.
>
>
> Did you add "-d 5" to the postmaster options? Maybe this will give you
> a better idea of how far postmaster is getting in its shutdown process.
> Another option is the hack postmaster to log with timestamps...
I'll try the "-d 5" when I get the chance. As for the option to "hack
postmaster", I don't feel comfortable enough with the code to go that
route. That requires recompiling from source, getting into a whole mess
of things that, though I wish I could, I really don't have time to do.
My FireDaemon hack isn't great, but it's working just fine for me as a
"spit & nails" patch.
I just wanted to determine if PostgreSQL was shutting down ok (which
your comments above and the log seem to indicate may or may not be the
case as it's getting 2 termination signals...so who wins?), and also to
make sure those new to PostgreSQL under Cygwin are aware of the
limitations of the environment (in this case, more so in Windows than
anything). I guess some could argue that maybe there should be some
kind of Cygwin NT service that all other Cygwin packages that run as NT
services should depend on, where that Cygwin service made sure all the
/etc/rc.d init scripts were run prior to things like PostgreSQL firing
up, giving a "truer" Unix experience. But this is beyond the scope of
where this all started, and may require discussion on a different
mailing list. I'm in deeper here than I intended.
Frank,
On Wed, May 28, 2003 at 06:26:59PM -0400, Frank Seesink wrote:
> Jason Tishler wrote:
> >I'm concerned that the Cygwin DLL is actually sending a SIGTERM to
> >the postmaster even though cygrunsrv is going to send a SIGINT too.
> >Does the postmaster log indicate a "smart shutdown" or "fast
> >shutdown" when the pid file is not deleted?
>
> I did the following:
>
> [snip]
>
> The following is the contents of /var/log/postmaster.log:
> ____________________________________________________________
> [snip]
> LOG: smart shutdown request
> LOG: shutting down
> LOG: fast shutdown request
> [snip]
> ____________________________________________________________
>
> From the above, it appears that PostgreSQL first receives a "smart
> shutdown request", followed by a "fast shutdown request". Are we
> getting closer? :-)
Yes! I can reproduce the problem under 2000 too. But, for some reason,
my database still shuts down cleanly.
Anyway, I tried to solve this in cygrunsrv but I was unsuccessful (which
is obvious in hindsight). I will work with the Cygwin developers to try
to solve this in the Cygwin DLL. I will report back when I have status.
> >I would call the above "quick and dirty". I wasn't clear but I
> >assumed the following:
> >
> > 1. It would only be invoked via net start which will prevent
> > multiple instances.
>
> Actually, I understand what you mean, but technically, no this is not
> true. If I do a 'net start postmaster' from the command line when a
> copy is already running, this script will delete postmaster.pid and
> fire up a 2nd copy.
I just tried my hack and it worked as advertised:
$ echo (</proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/postmaster/Parameters/AppPath)
/usr/local/bin/postmaster.sh
$ cat /usr/local/bin/postmaster.sh
#!/bin/sh
rm -f /usr/share/postgresql/data/postmaster.pid
/usr/bin/postmaster $*
$ net start | fgrep postmaster
postmaster
$ net start postmaster
The requested service has already been started.
More help is available by typing NET HELPMSG 2182.
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:
...
>>[snip]
>>
>>The following is the contents of /var/log/postmaster.log:
>>____________________________________________________________
>>[snip]
>>LOG: smart shutdown request
>>LOG: shutting down
>>LOG: fast shutdown request
>>[snip]
>>____________________________________________________________
>>
>From the above, it appears that PostgreSQL first receives a "smart
>>shutdown request", followed by a "fast shutdown request". Are we
>>getting closer? :-)
>
>
> Yes! I can reproduce the problem under 2000 too. But, for some reason,
> my database still shuts down cleanly.
>
> Anyway, I tried to solve this in cygrunsrv but I was unsuccessful (which
> is obvious in hindsight). I will work with the Cygwin developers to try
> to solve this in the Cygwin DLL. I will report back when I have status.
Thanks for all your help in this.
...
> I just tried my hack and it worked as advertised:
>
> $ echo (</proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/postmaster/Parameters/AppPath)
> /usr/local/bin/postmaster.sh
> $ cat /usr/local/bin/postmaster.sh
> #!/bin/sh
> rm -f /usr/share/postgresql/data/postmaster.pid
> /usr/bin/postmaster $*
>
> $ net start | fgrep postmaster
> postmaster
> $ net start postmaster
> The requested service has already been started.
>
> More help is available by typing NET HELPMSG 2182.
Ahhh, I see now. Sorry, forgot NT/2K/XP will prevent the multiple
instances. Was thinking *nix. My bad. As long as you treat
'postmaster' solely as an NT service and don't try to launch the
executable from the BASH shell, for example (and why would you?), this
will work great. It will fail if someone end-runs the NT service
aspect, but we have to have faith that users have enough sense not to do
that (e.g., after installing/running 'postmaster' as an NT service, they
don't try to follow the manual instructions for firing up PostgreSQL as
listed in the first section of the readme).
Thanks. This script beats my hack by a mile. Much cleaner.
Sorry, I haven't been religiously reading this list in the last 2 weeks or I would've replied sooner. I have written a service for XP in perl (using ActiveState's not cygwin's perl). In this service, perl uses Win32::Process::Create() to run pg_ctl via bash. This works great. At service startup, pg_ctl starts up the database. There is a small hitch here in that pg_ctl returns before postgres is actually "ready", so the service currently waits for an amount of time that seems to guarantee startup. However, I plan on changing it to try and establish a connection to the database before informing Windows that the service is successfully "started", or failing if it can't ever establish a connection after some reasonable time. For shutdown, the service runs pg_ctl again, and waits for the pg_ctl/bash process to exit before returning. The database really is shutdown before pg_ctl returns. For good measure, I then delete any cygipc memory mapped files, the pid file, and any lock files that should not still be hanging around anyway. The main service loop of this service doesn't do anything but sleep. But I plan on using it in a particular project to periodically call some stored procs to drive some functionality that has no other place to occur. This service runs in the postgres user context and seems to be operating fine in testing so far. Once I get it cleaned up, and make it a little more generalized, I'll make it available if there's any interest. Of course, it requires ActiveState perl and a couple of extra modules such Win32::Daemon from roth.net. I don't know if it would work under cygwin's perl or not. Later, McC
Frank, On Thu, May 29, 2003 at 02:26:03PM -0400, Frank Seesink wrote: > Thanks. This script beats my hack by a mile. Much cleaner. Except that it hangs when the service is stopped. :,( I even tried running postmaster in the background and waiting on it. Unfortunately, I believe that there is a bug in Cygwin that prevents the signal from being delivered to the shell script until the wait returns. Kind of a catch 22... See the attached for my latest attempt. 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 Thu, May 29, 2003 at 11:01:40AM -0400, Jason Tishler wrote:
> Anyway, I tried to solve this in cygrunsrv but I was unsuccessful
> (which is obvious in hindsight). I will work with the Cygwin
> developers to try to solve this in the Cygwin DLL. I will report back
> when I have status.
I'm very happy to report the above is fixed in Cygwin CVS:
http://cygwin.com/ml/cygwin-cvs/2003-q2/msg00168.html
This change will be available in the next Cygwin snapshot and eventually
the next Cygwin release, 1.5.0.
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