Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
X-Authentication-Warning: shell-2.enteract.com: fcy set sender to fred AT ontosys DOT com using -f
Date: Mon, 16 Jul 2001 11:51:00 -0500
From: Fred Yankowski <fred AT ontosys DOT com>
To: cygwin AT cygwin DOT com, pgsql-cygwin AT postgresql DOT org
Subject: Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1
Message-ID: <20010716115100.A87766@enteract.com>
References: <20010716171908 DOT V25442 AT cygbert DOT vinschen DOT de> <20010716113429 DOT D614 AT dothill DOT com> <20010716182727 DOT Y25442 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010716182727.Y25442@cygbert.vinschen.de>; from cygwin@cygwin.com on Mon, Jul 16, 2001 at 06:27:27PM +0200

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 AT OntoSys DOT 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/