Updated: cygrunsrv-0.92-2

Corinna Vinschen cygwin-apps@cygwin.com
Fri May 18 09:30:00 GMT 2001

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
* 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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

More information about the Cygwin-apps mailing list