public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* RE: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
@ 2001-07-12  3:26 Riaan Labuschagne
  2001-07-12  4:37 ` Corinna Vinschen
  2001-07-12  8:19 ` Fred Yankowski
  0 siblings, 2 replies; 17+ messages in thread
From: Riaan Labuschagne @ 2001-07-12  3:26 UTC (permalink / raw)
  To: cygwin; +Cc: vinschen

Dear Corinna,

I have used your Cygrunsrv to run PostgreSQL on Windows. Everything works
perfectly. I read through your docs and got it right first time.

I have no previous knowledge of Unix/Linux other than installing Red Hat, so
your software works and is well documented. I must commend you on a job well
done and if you ever need references you can put my name on top of the list.

Thanks again.

Riaan Labuschagne
e-mail: riaan@radioretail.co.za
+27 82 567 9063
+27 21 982 2223
+27 21 982 2225 (fax)
Visit http://www.radioretail.co.za



-----Original Message-----
From: Corinna Vinschen [ mailto:vinschen@redhat.com ]
Sent: 12 July 2001 10:56
To: cygwin@cygwin.com
Subject: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1


I have updated cygrunsrv to version 0.94-1 which adds the following
features:

- New option `--shutdown' to send a signal to the application on
  system shutdown, allowing the application to perform cleanup
  actions on shutdown.

- New option `--chdir' to allow running the application in another
  current directory.

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com web page.  This downloads setup.exe to your system.

Run setup and answer all of the questions.  The mirrors below have the
latest version of this package:

ftp://gd.tuwien.ac.at/gnu/cygwin/ (Austria)
ftp://ftp.mirror.ac.uk/sites/sourceware.cygnus.com/pub/cygwin/ (UK)
ftp://ftp.sunsite.utk.edu/pub/cygwin/ (US)

Note that if this is the first time that you've run the new GUI version
of setup, it will currently download the whole cygwin net release again.
After this point it will only download what is needed.

If you have questions or comments, please send them to the Cygwin
mailing list at:  cygwin@cygwin.com .  I would appreciate if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe to the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-12  3:26 [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1 Riaan Labuschagne
@ 2001-07-12  4:37 ` Corinna Vinschen
  2001-07-12  8:19 ` Fred Yankowski
  1 sibling, 0 replies; 17+ messages in thread
From: Corinna Vinschen @ 2001-07-12  4:37 UTC (permalink / raw)
  To: cygwin

On Thu, Jul 12, 2001 at 12:09:56PM +0200, Riaan Labuschagne wrote:
> Dear Corinna,
> 
> I have used your Cygrunsrv to run PostgreSQL on Windows. Everything works
> perfectly. I read through your docs and got it right first time.
> 
> I have no previous knowledge of Unix/Linux other than installing Red Hat, so
> your software works and is well documented. I must commend you on a job well
> done and if you ever need references you can put my name on top of the list.
> 
> Thanks again.

You're welcome.

I can't take these thanks without passing on them to Fred Yankowski
<fred@ontosys.com> for major contributions which let postgreSQL run
smoothly under cygrunsrv and Charles S. Wilson <cwilson@ece.gatech.edu>
for the major part of the documentation, though.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-12  3:26 [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1 Riaan Labuschagne
  2001-07-12  4:37 ` Corinna Vinschen
@ 2001-07-12  8:19 ` Fred Yankowski
  2001-07-12  8:46   ` Jason Tishler
  1 sibling, 1 reply; 17+ messages in thread
From: Fred Yankowski @ 2001-07-12  8:19 UTC (permalink / raw)
  To: Riaan Labuschagne; +Cc: cygwin

I'm glad to hear that others are having success running PostgreSQL via
cygrunsrv.

In my testing though, there is one remaining problem in using
PostgreSQL under Cygwin:  the postmaster sometimes does not shutdown
cleanly during NT shutdown and therefore fails to start up on the next
NT restart.  To work around this it's necessary to manually remove the
postmaster.pid file and start the postmaster service.

This problem happens because Cygwin sends SIGHUP to each process
during NT shutdown.  The postmaster process reacts to SIGHUP by
starting to reload its configuration files (as designed) and this
somehow jams up a concurrent attempt to shutdown the postmaster.  I've
got a simple patch to the PostgreSQL code to have it ignore SIGHUP
when built for Cygwin -- in both the postmaster and any postgresql
processes -- but I haven't found the time to pursue a better solution
or to champion inclusion of this patch into the distributed PostgreSQL.

I'd be glad to hear from anyone who has thoughts about how to solve
this SIGHUP problem.

On Thu, Jul 12, 2001 at 12:09:56PM +0200, Riaan Labuschagne wrote:
> I have used your Cygrunsrv to run PostgreSQL on Windows. Everything works
> perfectly. I read through your docs and got it right first time.

-- 
Fred Yankowski           fred@OntoSys.com      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-12  8:19 ` Fred Yankowski
@ 2001-07-12  8:46   ` Jason Tishler
  2001-07-12  9:42     ` Fred Yankowski
  0 siblings, 1 reply; 17+ messages in thread
From: Jason Tishler @ 2001-07-12  8:46 UTC (permalink / raw)
  To: Fred Yankowski; +Cc: Riaan Labuschagne, cygwin

Fred,

On Thu, Jul 12, 2001 at 10:19:49AM -0500, Fred Yankowski wrote:
> This problem happens because Cygwin sends SIGHUP to each process
> during NT shutdown.  The postmaster process reacts to SIGHUP by
> starting to reload its configuration files (as designed) and this
> somehow jams up a concurrent attempt to shutdown the postmaster.  I've
> got a simple patch to the PostgreSQL code to have it ignore SIGHUP
> when built for Cygwin -- in both the postmaster and any postgresql
> processes -- but I haven't found the time to pursue a better solution
> or to champion inclusion of this patch into the distributed PostgreSQL.

Please post your patch -- I've been waiting with bated breath since you
first mentioned it.  :,)  I will be quite willing to champion it (or a
better solution, if one can be devised) for inclusion into PostgreSQL CVS.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: 732.264.8770 x235
Dot Hill Systems Corp.               Fax:   732.264.8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-12  8:46   ` Jason Tishler
@ 2001-07-12  9:42     ` Fred Yankowski
  2001-07-16  7:04       ` Jason Tishler
  0 siblings, 1 reply; 17+ messages in thread
From: Fred Yankowski @ 2001-07-12  9:42 UTC (permalink / raw)
  To: cygwin; +Cc: pgsql-cygwin

On Thu, Jul 12, 2001 at 11:45:39AM -0400, Jason Tishler wrote:
> Please post your patch -- I've been waiting with bated breath since you
> first mentioned it.  :,)  I will be quite willing to champion it (or a
> better solution, if one can be devised) for inclusion into PostgreSQL CVS.

OK, here's the patch.  It's crude, simply causing the SIGHUP handlers
(one for postmaster and one for postgres) to return immediately
without triggering the normal config-file-reloading response.

BTW, while testing this patch again after a 'cvs update' I notice that
I've got more 'postgres' processes running than usual.  In the idle
state I expect to have just one process named 'postgres' running; it's
actually the postmaster and has cygrunsrv as its parent.  But now I've
got two other postgres processes, one a child of the postmaster and
the other a child of the first.  I don't remember seeing this before.
I don't have any client programs running.  Stopping and restarting the
service results in the same situation.  Starting a client causes a new
postgres child process of the postmaster to run while the client is
connected, as usual.  I'm puzzled about those two other processes.

-- 
Fred Yankowski           fred@OntoSys.com      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

--

Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.229
diff -u -p -r1.229 postmaster.c
--- src/backend/postmaster/postmaster.c 2001/06/29 16:05:57     1.229
+++ src/backend/postmaster/postmaster.c 2001/07/12 16:34:29
@@ -1284,6 +1284,18 @@ SIGHUP_handler(SIGNAL_ARGS)
        int                     save_errno = errno;

        PG_SETMASK(&BlockSig);
+#ifdef __CYGWIN__
+       /*
+        * Ignore SIGHUP since Cygwin sends a SIGHUP when NT is being
+        * shut down.  Attempting to handle this signal as normal
+        * seems to block the concurrent activity to shutdown the
+        * postmaster.
+        */
+       if (DebugLvl)
+         postmaster_error("ignoring caught SIGHUP in postmaster");
+       errno = save_errno;
+       return;
+#endif

        if (Shutdown <= SmartShutdown)
        {
Index: src/backend/tcop/postgres.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/tcop/postgres.c,v
retrieving revision 1.227
diff -u -p -r1.227 postgres.c
--- src/backend/tcop/postgres.c 2001/06/29 16:05:56     1.227
+++ src/backend/tcop/postgres.c 2001/07/12 16:34:31
@@ -1022,6 +1022,10 @@ FloatExceptionHandler(SIGNAL_ARGS)
 static void
 SigHupHandler(SIGNAL_ARGS)
 {
+#ifdef __CYGWIN__
+       elog(DEBUG, "ignoring caught SIGHUP in postgres\n");
+       return;
+#endif
        got_SIGHUP = true;
 }

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-12  9:42     ` Fred Yankowski
@ 2001-07-16  7:04       ` Jason Tishler
  2001-07-16  8:19         ` Corinna Vinschen
  2001-07-16  9:36         ` Fred Yankowski
  0 siblings, 2 replies; 17+ messages in thread
From: Jason Tishler @ 2001-07-16  7:04 UTC (permalink / raw)
  To: Fred Yankowski; +Cc: cygwin, pgsql-cygwin

Fred,

On Thu, Jul 12, 2001 at 11:42:08AM -0500, Fred Yankowski wrote:
> On Thu, Jul 12, 2001 at 11:45:39AM -0400, Jason Tishler wrote:
> > Please post your patch -- I've been waiting with bated breath since you
> > first mentioned it.  :,)  I will be quite willing to champion it (or a
> > better solution, if one can be devised) for inclusion into PostgreSQL CVS.
> 
> OK, here's the patch.  It's crude, simply causing the SIGHUP handlers
> (one for postmaster and one for postgres) to return immediately
> without triggering the normal config-file-reloading response.

What about trying to tackle this from another point of view?  I'm not
sure if this is doable or acceptable, but what about adding logic to the
Cygwin DLL so that it does not send SIGHUP (to itself) when the process is
running under cygrunsrv?  If this is deemed accepted, does anyone have any
ideas on what is the best way to determine when running under cygrunsrv?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: 732.264.8770 x235
Dot Hill Systems Corp.               Fax:   732.264.8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-16  7:04       ` Jason Tishler
@ 2001-07-16  8:19         ` Corinna Vinschen
  2001-07-16  8:34           ` Jason Tishler
  2001-07-16  9:36         ` Fred Yankowski
  1 sibling, 1 reply; 17+ messages in thread
From: Corinna Vinschen @ 2001-07-16  8:19 UTC (permalink / raw)
  To: cygwin; +Cc: Fred Yankowski, pgsql-cygwin

On Mon, Jul 16, 2001 at 10:04:17AM -0400, Jason Tishler wrote:
> Fred,
> 
> On Thu, Jul 12, 2001 at 11:42:08AM -0500, Fred Yankowski wrote:
> > On Thu, Jul 12, 2001 at 11:45:39AM -0400, Jason Tishler wrote:
> > > Please post your patch -- I've been waiting with bated breath since you
> > > first mentioned it.  :,)  I will be quite willing to champion it (or a
> > > better solution, if one can be devised) for inclusion into PostgreSQL CVS.
> > 
> > OK, here's the patch.  It's crude, simply causing the SIGHUP handlers
> > (one for postmaster and one for postgres) to return immediately
> > without triggering the normal config-file-reloading response.
> 
> What about trying to tackle this from another point of view?  I'm not
> sure if this is doable or acceptable, but what about adding logic to the
> Cygwin DLL so that it does not send SIGHUP (to itself) when the process is
> running under cygrunsrv?  

Hmmm, sounds like an ugly hack to me...

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-16  8:19         ` Corinna Vinschen
@ 2001-07-16  8:34           ` Jason Tishler
  2001-07-16  9:27             ` Corinna Vinschen
  0 siblings, 1 reply; 17+ messages in thread
From: Jason Tishler @ 2001-07-16  8:34 UTC (permalink / raw)
  To: cygwin, Fred Yankowski, pgsql-cygwin

Corrina,

On Mon, Jul 16, 2001 at 05:19:08PM +0200, Corinna Vinschen wrote:
> On Mon, Jul 16, 2001 at 10:04:17AM -0400, Jason Tishler wrote:
> > What about trying to tackle this from another point of view?  I'm not
> > sure if this is doable or acceptable, but what about adding logic to the
> > Cygwin DLL so that it does not send SIGHUP (to itself) when the process is
> > running under cygrunsrv?  
> 
> Hmmm, sounds like an ugly hack to me...

Which is why I couched the above with "acceptable."  However, there are
other Unix daemons (e.g., inetd) that will respond to SIGHUP in a similar
manner.  Is modifying all of them, instead of just the Cygwin DLL, better?

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: 732.264.8770 x235
Dot Hill Systems Corp.               Fax:   732.264.8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-16  8:34           ` Jason Tishler
@ 2001-07-16  9:27             ` Corinna Vinschen
  2001-07-16  9:51               ` Fred Yankowski
  2001-07-18 12:11               ` Jason Tishler
  0 siblings, 2 replies; 17+ messages in thread
From: Corinna Vinschen @ 2001-07-16  9:27 UTC (permalink / raw)
  To: cygwin; +Cc: Fred Yankowski, pgsql-cygwin

On Mon, Jul 16, 2001 at 11:34:29AM -0400, Jason Tishler wrote:
> Corrina,
> 
> On Mon, Jul 16, 2001 at 05:19:08PM +0200, Corinna Vinschen wrote:
> > On Mon, Jul 16, 2001 at 10:04:17AM -0400, Jason Tishler wrote:
> > > What about trying to tackle this from another point of view?  I'm not
> > > sure if this is doable or acceptable, but what about adding logic to the
> > > Cygwin DLL so that it does not send SIGHUP (to itself) when the process is
> > > running under cygrunsrv?  
> > 
> > Hmmm, sounds like an ugly hack to me...
> 
> Which is why I couched the above with "acceptable."  However, there are
> other Unix daemons (e.g., inetd) that will respond to SIGHUP in a similar
> manner.  Is modifying all of them, instead of just the Cygwin DLL, better?

That's not what I meant. I just don't like a solution which checks
for a specific situation which might change in future due to reasons
we don't know yet.

Would perhaps changing the general behaviour of Cygwin help?

For example when changing the runlevel on a Linux system is requested,
init(8) sends a SIGTERM to processes which aren't defined on the new
runlevel. Which is a similar situation, IMO. Perhaps changing Cygwin
from sending SIGHUP to sending SIGTERM makes any sense?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-16  7:04       ` Jason Tishler
  2001-07-16  8:19         ` Corinna Vinschen
@ 2001-07-16  9:36         ` Fred Yankowski
  1 sibling, 0 replies; 17+ messages in thread
From: Fred Yankowski @ 2001-07-16  9:36 UTC (permalink / raw)
  To: cygwin, pgsql-cygwin

On Mon, Jul 16, 2001 at 10:04:17AM -0400, Jason Tishler wrote:
> What about trying to tackle this from another point of view?  I'm not
> sure if this is doable or acceptable, but what about adding logic to the
> Cygwin DLL so that it does not send SIGHUP (to itself) when the process is
> running under cygrunsrv?  If this is deemed accepted, does anyone have any
> ideas on what is the best way to determine when running under cygrunsrv?

That solution would be fine by me.  In fact, I would prefer it since
PostgreSQL would then not require _any_ source code changes to allow
operation as a win32 service.

I wonder if Cygwin should generate SIGHUP in this situation for any
process, not just cygrunsrv.  The ctrl_c_handler() function in
exceptions.cc sends SIGHUP to its own process when handling the
CTRL_CLOSE_EVENT and CTRL_SHUTDOWN_EVENT signals from the system.
According to MSDN [1], CTRL_SHUTDOWN_EVENT will only be received by
service processes.  Unix-based daemons don't expect to be associated
with a terminal (except for debugging modes of operation) and, if they
handle SIGHUP at all, use SIGHUP as a manually-invoked signal to
trigger administrative operations, not a signal indicating system
shutdown.  So what good is it for Cygwin to send SIGHUP in the event
of CTRL_SHUTDOWN_EVENT?

I don't have time to rebuild and test the Cygwin DLL right now, but
what I'm suggesting is represented by the attached patch.

[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/hh/winbase/conchar_5zz9.asp

-- 
Fred Yankowski           fred@OntoSys.com      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

--
Index: exceptions.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
retrieving revision 1.91
diff -u -p -r1.91 exceptions.cc
--- exceptions.cc       2001/06/28 02:19:57     1.91
+++ exceptions.cc       2001/07/16 16:22:11
@@ -900,7 +900,8 @@ ctrl_c_handler (DWORD type)
        for each Cygwin process window that's open when the computer
        is shut down or console window is closed. */
     {
-      sig_send (NULL, SIGHUP);
+      if (type == CTRL_CLOSE_EVENT)
+       sig_send (NULL, SIGHUP);
       return FALSE;
     }
   tty_min *t = cygwin_shared->tty.get_tty (myself->ctty);

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-16  9:27             ` Corinna Vinschen
@ 2001-07-16  9:51               ` Fred Yankowski
  2001-07-16 10:16                 ` Corinna Vinschen
  2001-07-18 12:11               ` Jason Tishler
  1 sibling, 1 reply; 17+ messages in thread
From: Fred Yankowski @ 2001-07-16  9:51 UTC (permalink / raw)
  To: cygwin, pgsql-cygwin

On Mon, Jul 16, 2001 at 06:27:27PM +0200, Corinna Vinschen wrote:
> For example when changing the runlevel on a Linux system is requested,
> init(8) sends a SIGTERM to processes which aren't defined on the new
> runlevel. Which is a similar situation, IMO. Perhaps changing Cygwin
> from sending SIGHUP to sending SIGTERM makes any sense?

Sending SIGTERM rather than SIGHUP does seem more appropriate for this
case in general.  However, it might not work well for PostgreSQL.

PostgreSQL has three modes of shutdown (that I know of):  SIGTERM
triggers a "smart" shutdown mode that will wait for clients to
disconnect first; SIGINT triggers "fast" shutdown that aborts current
transactions and shuts down cleanly very quickly; SIGQUIT triggers
"immediate" shutdown that quits with minimal attempt to clean up
first, leading to recovery on the next restart.  Unfortunately for our
case, the SIGTERM mode is not appropriate for system shutdown because
we would block until interactive clients all happen to disconnect,
which is likely to cause the win32 system to just kill the postgresql
processes after it waits the maximum allowed time for services to
shutdown.

Cygrunsrv can send an arbitrary signal to the managed process in the
event of system shutdown, and I configure it to send SIGINT for
PostgreSQL to trigger smart shutdown.  The problem, as I see it, is
that there is a race condition and if we have Cygwin send SIGTERM
rather than SIGHUP then the PostgreSQL processes may get that before
the SIGINT sent by cygrunsrv and will embark on the smart shutdown
path.  I believe (but, I realize, I'm not sure) that PostgreSQL will
continue with the "smart" shutdown even on later receipt of SIGINT.

A Unix system would typically give daemon processes a chance to
shutdown cleanly between run-levels through the use of /etc/init.d
scripts (or the like), before hammering them with a signal.
Cygrunsrv's --shutdown option gives us a limited capability similar to
those init.d scripts, but unfortunately doesn't get the same priority
in time that the scripts get.

-- 
Fred Yankowski           fred@OntoSys.com      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-16  9:51               ` Fred Yankowski
@ 2001-07-16 10:16                 ` Corinna Vinschen
  2001-07-16 11:15                   ` Fred Yankowski
  0 siblings, 1 reply; 17+ messages in thread
From: Corinna Vinschen @ 2001-07-16 10:16 UTC (permalink / raw)
  To: cygwin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

On Mon, Jul 16, 2001 at 11:51:00AM -0500, Fred Yankowski wrote:
> On Mon, Jul 16, 2001 at 06:27:27PM +0200, Corinna Vinschen wrote:
> > For example when changing the runlevel on a Linux system is requested,
> > init(8) sends a SIGTERM to processes which aren't defined on the new
> > runlevel. Which is a similar situation, IMO. Perhaps changing Cygwin
> > from sending SIGHUP to sending SIGTERM makes any sense?
> 
> Sending SIGTERM rather than SIGHUP does seem more appropriate for this
> case in general.  However, it might not work well for PostgreSQL.
> [...]
> A Unix system would typically give daemon processes a chance to
> shutdown cleanly between run-levels through the use of /etc/init.d
> scripts (or the like), before hammering them with a signal.

Not neccessarily. From the Linux man page init(8):

       When  init  is  requested to change the runlevel, it sends
       the warning signal SIGTERM to all processes that are unde­
       fined in the new runlevel.  It then waits 5 seconds before
       forcibly terminating these processes via the SIGKILL  sig­
       nal.

5 seconds... that's not too much either.

> Cygrunsrv's --shutdown option gives us a limited capability similar to
> those init.d scripts, but unfortunately doesn't get the same priority
> in time that the scripts get.

According to MSDN we have some more time per service:

	By default, a service has approximately 20 seconds to perform
	cleanup tasks before the system shuts down. 

and it can be longer by changing the services behaviour:

	If the service needs more time to clean up, it sends
	STOP_PENDING status messages, along with a wait hint, so
	the service controller knows how long to wait before
	reporting to the system that service shutdown is complete. 

with the exception:

	However, there is a limit to how long the service controller
	will wait, to prevent a service from stopping shutdown. To
	change this time limit, modify the WaitToKillServiceTimeout
	value in the following registry key: 

	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

We could even add an option to cygrunsrv which adds the feature to send
STOP_PENDING status messages every 5 seconds or so while the depending
service application performs it's cleanup.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-16 10:16                 ` Corinna Vinschen
@ 2001-07-16 11:15                   ` Fred Yankowski
  0 siblings, 0 replies; 17+ messages in thread
From: Fred Yankowski @ 2001-07-16 11:15 UTC (permalink / raw)
  To: cygwin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On Mon, Jul 16, 2001 at 07:15:53PM +0200, Corinna Vinschen wrote:
> > A Unix system would typically give daemon processes a chance to
> > shutdown cleanly between run-levels through the use of /etc/init.d
> > scripts (or the like), before hammering them with a signal.
> 
> Not neccessarily. From the Linux man page init(8):
> 
>        When  init  is  requested to change the runlevel, it sends
>        the warning signal SIGTERM to all processes that are unde­
>        fined in the new runlevel.  It then waits 5 seconds before
>        forcibly terminating these processes via the SIGKILL  sig­
>        nal.

I think that applies only to processes that init is managing directly
because of their entries in /etc/inittab.  In systems like Debian
GNU/Linux that provide /etc/init.d scripts, init runs /etc/init.d/rc
on any change in run-level and that script goes through the
appropriate /etc/rc?.d directory and runs all the K* and S* (kill and
start) symlinked scripts there.  I'm not aware of any particular limit
on how long those scripts can take -- I've seen a run-level change
take a _very_ long time when I wrote a stop script incorrectly and the
script would hang.  It doesn't look like init ever sends _any_ signal
to those processes that are managed indirectly through init.d scripts
-- it doesn't even know about those processes.

In the case of Cygwin, I'm concerned that a SIGTERM signal sent by
ctrl_c_handler() would beat the signal sent (via the --shutdown
option) by cygrunsrv, causing the daemon to embark on the wrong
shutdown mode.

The amount of time allowed for shutdown might be another issue,
but we could address that one as you suggested, by having cygrunsrv
interact with the Service Control Manager to request more time.  I
haven't found a need for this in practice.

-- 
Fred Yankowski           fred@OntoSys.com      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-16  9:27             ` Corinna Vinschen
  2001-07-16  9:51               ` Fred Yankowski
@ 2001-07-18 12:11               ` Jason Tishler
  2001-07-18 13:20                 ` Corinna Vinschen
  2001-07-19  8:26                 ` Fred Yankowski
  1 sibling, 2 replies; 17+ messages in thread
From: Jason Tishler @ 2001-07-18 12:11 UTC (permalink / raw)
  To: cygwin; +Cc: pgsql-cygwin

Corinna,

On Mon, Jul 16, 2001 at 06:27:27PM +0200, Corinna Vinschen wrote:
> Perhaps changing Cygwin from sending SIGHUP to sending SIGTERM makes
> any sense?

Yes, I believe that this is the way to go -- at least for PostgreSQL...

On Mon, Jul 16, 2001 at 11:51:00AM -0500, Fred Yankowski wrote:
> Sending SIGTERM rather than SIGHUP does seem more appropriate for this
> case in general.  However, it might not work well for PostgreSQL.

I appear to have empirical evidence that indicates that PostgreSQL
can tolerate receiving SIGTERM and/or SIGINT during an NT shutdown.

My procedure is as follows:

    1. I applied the attached patch, rebuilt my Cygwin DLL, and
       installed it.

    2. I installed postmaster under cygrunsrv as follows:

        $ cygrunsrv --install postmaster --path /usr/bin/postmaster \
          --args "-D /usr/share/postgresql/data -i" --dep ipc-daemon \
          --termsig INT --user 'bhmco\jt' --shutdown

    3. I connected to this postmaster via psql running on another machine.

    4. I restarted this NT box.

The following are the messages displayed during shutdown and startup:

    Smart Shutdown request at Wed Jul 18 14:00:32 2001 [1]
    FATAL 1:  This connection has been terminated by the administrator. [2]
    DEBUG:  shutting down
    Fast Shutdown request at Wed Jul 18 14:00:33 2001 [3]
    DEBUG:  database system is shut down
    DEBUG:  database system was shut down at 2001-07-18 14:00:35 

    [restart occurs here]

    DEBUG:  CheckPoint record at (0, 63186000)
    DEBUG:  Redo record at (0, 63186000); Undo record at (0, 0); Shutdown TRUE
    DEBUG:  NextTransactionId: 11662; NextOid: 414368
    DEBUG:  database system is in production state [4]

Message [1] is due to ctrl_c_handler() sending a SIGTERM instead of
SIGHUP to the postmaster process.  Message [2] is due to ctrl_c_handler()
sending a SIGTERM to the backend postgres process that is serving the
only connection (from psql) which causes it to terminate.  Note that
normally it is postmaster that sends this signal (not some other process).
Message [3] is due to cygrunsrv responding to the NT shutdown message
and in turn sending a SIGINT to postmaster.  Note that this seems to
indicate that a Fast Shutdown can interrupt and supersede a Smart one.
Message [4] indicates that PostgreSQL was able to restart without any
manual intervention.

Although the above is not quite how PostgreSQL shutdowns on other
platforms, it is very close and seems to work.

Should I submit the attached patch (with ChangeLog) to cygwin-patches
for consideration?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: 732.264.8770 x235
Dot Hill Systems Corp.               Fax:   732.264.8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-18 12:11               ` Jason Tishler
@ 2001-07-18 13:20                 ` Corinna Vinschen
  2001-07-19  8:26                 ` Fred Yankowski
  1 sibling, 0 replies; 17+ messages in thread
From: Corinna Vinschen @ 2001-07-18 13:20 UTC (permalink / raw)
  To: cygwin; +Cc: pgsql-cygwin

On Wed, Jul 18, 2001 at 03:11:42PM -0400, Jason Tishler wrote:
>     Smart Shutdown request at Wed Jul 18 14:00:32 2001 [1]
>     FATAL 1:  This connection has been terminated by the administrator. [2]
>     DEBUG:  shutting down
>     Fast Shutdown request at Wed Jul 18 14:00:33 2001 [3]
>     DEBUG:  database system is shut down
>     DEBUG:  database system was shut down at 2001-07-18 14:00:35 
> 
>     [restart occurs here]
> 
>     DEBUG:  CheckPoint record at (0, 63186000)
>     DEBUG:  Redo record at (0, 63186000); Undo record at (0, 0); Shutdown TRUE
>     DEBUG:  NextTransactionId: 11662; NextOid: 414368
>     DEBUG:  database system is in production state [4]
> 
> Message [1] is due to ctrl_c_handler() sending a SIGTERM instead of
> SIGHUP to the postmaster process.  Message [2] is due to ctrl_c_handler()
> sending a SIGTERM to the backend postgres process that is serving the
> only connection (from psql) which causes it to terminate.  Note that
> normally it is postmaster that sends this signal (not some other process).
> Message [3] is due to cygrunsrv responding to the NT shutdown message
> and in turn sending a SIGINT to postmaster.  Note that this seems to
> indicate that a Fast Shutdown can interrupt and supersede a Smart one.
> Message [4] indicates that PostgreSQL was able to restart without any
> manual intervention.
> 
> Although the above is not quite how PostgreSQL shutdowns on other
> platforms, it is very close and seems to work.
> 
> Should I submit the attached patch (with ChangeLog) to cygwin-patches
> for consideration?

Yep! I would like Chris "Mister Signal" Faylor to review the patch.

Thanks for investigating the situation,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
  2001-07-18 12:11               ` Jason Tishler
  2001-07-18 13:20                 ` Corinna Vinschen
@ 2001-07-19  8:26                 ` Fred Yankowski
  1 sibling, 0 replies; 17+ messages in thread
From: Fred Yankowski @ 2001-07-19  8:26 UTC (permalink / raw)
  To: cygwin, pgsql-cygwin

On Wed, Jul 18, 2001 at 03:11:42PM -0400, Jason Tishler wrote:
> I appear to have empirical evidence that indicates that PostgreSQL
> can tolerate receiving SIGTERM and/or SIGINT during an NT shutdown.
...
> Note that this seems to
> indicate that a Fast Shutdown can interrupt and supersede a Smart one.
> Message [4] indicates that PostgreSQL was able to restart without any
> manual intervention.

Excellent!  Your experimental results trump my hunch, big time.

> Should I submit the attached patch (with ChangeLog) to cygwin-patches
> for consideration?

Yes, please.  This patch would seem to provide the last piece needed
(along with cygrunsrv) to make PostgreSQL robust as an NT/Win2000
service.  And with no changes whatsoever to PostgreSQL code -- bonus!

-- 
Fred Yankowski           fred@OntoSys.com      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
@ 2001-07-12  1:55 Corinna Vinschen
  0 siblings, 0 replies; 17+ messages in thread
From: Corinna Vinschen @ 2001-07-12  1:55 UTC (permalink / raw)
  To: cygwin

I have updated cygrunsrv to version 0.94-1 which adds the following
features:

- New option `--shutdown' to send a signal to the application on
  system shutdown, allowing the application to perform cleanup
  actions on shutdown.

- New option `--chdir' to allow running the application in another
  current directory.

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com web page.  This downloads setup.exe to your system.

Run setup and answer all of the questions.  The mirrors below have the
latest version of this package:

ftp://gd.tuwien.ac.at/gnu/cygwin/ (Austria)
ftp://ftp.mirror.ac.uk/sites/sourceware.cygnus.com/pub/cygwin/ (UK)
ftp://ftp.sunsite.utk.edu/pub/cygwin/ (US)

Note that if this is the first time that you've run the new GUI version
of setup, it will currently download the whole cygwin net release again.
After this point it will only download what is needed.

If you have questions or comments, please send them to the Cygwin
mailing list at:  cygwin@cygwin.com .  I would appreciate if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe to the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2001-07-19  8:26 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-12  3:26 [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1 Riaan Labuschagne
2001-07-12  4:37 ` Corinna Vinschen
2001-07-12  8:19 ` Fred Yankowski
2001-07-12  8:46   ` Jason Tishler
2001-07-12  9:42     ` Fred Yankowski
2001-07-16  7:04       ` Jason Tishler
2001-07-16  8:19         ` Corinna Vinschen
2001-07-16  8:34           ` Jason Tishler
2001-07-16  9:27             ` Corinna Vinschen
2001-07-16  9:51               ` Fred Yankowski
2001-07-16 10:16                 ` Corinna Vinschen
2001-07-16 11:15                   ` Fred Yankowski
2001-07-18 12:11               ` Jason Tishler
2001-07-18 13:20                 ` Corinna Vinschen
2001-07-19  8:26                 ` Fred Yankowski
2001-07-16  9:36         ` Fred Yankowski
  -- strict thread matches above, loose matches on Subject: below --
2001-07-12  1:55 Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).