Mail Archives: cygwin-apps/2001/05/18/11:36:42
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.
>
> That's a real problem in Cygwin and NT. Sending signals to
> a service is a Cygwin problem (yet) since the service is
> running in another thread while signal handling in Cygwin only
> works reliable for the main thread.
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
currently sends SIGTERM to the application when the service is
manually stopped and/or when cygrunsrv receives SIGHUP, SIGINT,
SIGQUIT, or SIGTERM.
What I need for the PostgreSQL case is to have cygrunsrv send SIGINT
(not SIGTERM) to the postgres application process (which happens to be
the "postmaster") when SERVICE_CONTROL_STOP is received. I suppose it
should do the same on receipt of any of the above four signals.
Allowing whoever configures cygrunsrv for postgres to specify the
particular signal to be used to stop the application would suffice.
> 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.
> > 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
might work out fine. Since my version triggered shutdown based on the
SERVICE_CONTROL_SHUTDOWN event, I didn't need a handler for that event
but did need to make sure that receipt of SIGHUP didn't immediately
terminate the service process.
> > I'm willing to help incorporate/patch such features into cygrunsrv, if
> > that matters.
>
> That would be really great :)
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?
> I think it's becoming more and more important to have a service
> startup environment which cuddles Cygwin processes so that most
> of the time nobody has to worry if a process can smoothly run as
> NT service process as well.
I agree. We should be able to support the NT-service-management code
in just one place -- cygrunsrv -- rather than duplicating in each
separate service. OTOH, some simple services such as ipc-daemon can
run as a single NT process when service-management is integrated into
them.
--
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
- Raw text -