Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Date: Fri, 18 May 2001 18:29:56 +0200
From: Corinna Vinschen <cygwin-apps AT cygwin DOT com>
To: cygapp <cygwin-apps AT cygwin DOT com>
Subject: Re: Updated: cygrunsrv-0.92-2
Message-ID: <20010518182956.D31266@cygbert.vinschen.de>
Mail-Followup-To: cygapp <cygwin-apps AT cygwin DOT com>
References: <20010517161408 DOT A60686 AT enteract DOT com> <20010518101617 DOT B31266 AT cygbert DOT vinschen DOT de> <20010518103001 DOT A61059 AT enteract DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010518103001.A61059@enteract.com>; from fred@ontosys.com on Fri, May 18, 2001 at 10:30:01AM -0500

On Fri, May 18, 2001 at 10:30:01AM -0500, Fred Yankowski wrote:
> On Fri, May 18, 2001 at 10:16:17AM +0200, Corinna Vinschen wrote:
> > > 1.  Some way to send specific signals to the daemon process to stop it
> > >     in both the stop and shutdown cases.
> > [...]
> I don't want to send signals to the cgyrunsrv process itself -- the
> one that has multiple threads as you mention -- but rather have
> cygrunsrv send specific signals to the underlying application that
> cygrunsrv earlier forked and execv'ed.  It looks as though cygrunsrv
> [...]
> What I need for the PostgreSQL case is to have cygrunsrv send SIGINT
> [...]
> Allowing whoever configures cygrunsrv for postgres to specify the
> particular signal to be used to stop the application would suffice.

We could define another optional command line option:

	--sig <signum/sigtxt>

to define which signal the application needs to do a graceful
exit. Default could still be 15/TERM.

> > Even worse: NT Shutdown is somewhat touchy. We should check what
> > we can do here.
> 
> Indeed, this has been a tricky thing to handle.  I've currently got
> service-management code working in a patched version of PostgreSQL,
> which accepts and handles the SERVICE_CONTROL_SHUTDOWN control event
> too.  The handler treats this exactly like the STOP case, sending
> SIGINT to the application process and gracefully shutting down the
> service.  It may be that catching SIGHUP as above would suffice to do
> the same thing.

Not really, AFAICT. MSDN tells us:

"The SERVICE_CONTROL_SHUTDOWN control code should only be processed by
 services that must absolutely clean up during shutdown, because there
 is a limited time (about 20 seconds) available for service shutdown.
 After this time expires, system shutdown proceeds regardless of whether
 service shutdown is complete. [...]

 If the service needs more time to clean up, it should send STOP_PENDING
 status messages, along with a wait hint, [...]. However, to prevent a
 service from stopping shutdown, there is a limit to how long the service
 controller will wait. [...]"

As a result, the current method isn't sufficient for shutdown since the
service thread simply hangs in `waitpid' until the child application
actually exited.

> > > 2.  Ignore SIGHUP.
> > 
> > Cygrunsrv tries to install a signal handler for SIGHUP and others
> > which for the above reason results in ignoring them :-(
> 
> I don't follow why that's a problem.  From what I see in version
> 0.92-2, the handler installed for SIGHUP (and the other handled
> signals as above) does lead to application and service shutdown.  That

I'm somewhat surprised. When I send SIGTERM to cygrunsrv, the signal
is silently ignored and cygrunsrv grabs all CPU time it can get.

> Well, which part should I work on?  Is there an online CVS with the
> code, or should I make patches relative to the 0.92-2 snapshot?

Currently we have the following TODO list:

* --sig <signal> option.
* --std{in,out,err} option as described in the cygwin mailing list.
* --dep(?) option for adding dependencies to other services.
* Reasonable SERVICE_CONTROL_SHUTDOWN behaviour.
* (not yet possible): Sending signals to cygrunsrv to perform various
  actions.
* Probably act still as service even if the child has forked/exited
  as SRVANY does.

What about the above --sig or the --dep option? I plan to add the
--std{in,out,err} options this weekend.

There's currently no CVS repository. At the moment I prefer getting
patches related to the latest version available (yes, .92-2 for now)
to this cygwin-apps list. ChangeLogs as for Cygwin, diffs in
`diff -up' format.

> OTOH, some simple services such as ipc-daemon can
> run as a single NT process when service-management is integrated into
> them. 

Which shouldn't be needed anymore if cygrunsrv can provide an
environment where all those daemons feel good.

Thanks for your help,
Corinna

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