Re: [ANNOUNCEMENT] Updated: cygrunsrv-0.94-1

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