Mail Archives: cygwin/2005/09/08/03:54:51
On Sep 7 23:43, Michael Brian Bentley wrote:
> We run an application under Windows 2003 Server Standard Edition as a
> service using Firedaemon. That application invokes ssh connections
> using the command
>
> c:\cygwin\bin\ssh -T -l fill_in_the_username
>
> with the appropriate ssh keys setup well ahead of time.
>
> When a user logs onto the W2k3 Server via Terminal Services Remote
> Desktop Connection [RDC], user can interact with the application.
> While looking at the service, user causes the application to start
> one or more ssh processes. These start to run and appear to work fine.
>
> When user logs out of the RDC session, the application running as a
> service continues, but the ssh processes end.
The service application is running with "Allow service to interact with
desktop" setting, right? And then it starts the ssh processes. The
ssh processes are started from the console window which the service has
opened, methinks.
Hmm.
> We believe the ssh processes are supposed to continue to completion
> because they were started by the service; indeed when we experiment
> with PuTTY and plink in place of ssh, they behave as we expect and
> run to completion instead of ending immediately as user logs out of
> the session.
>
> Interestingly, when we use any cygwin program like telnet, vi, they
> (all that we've tried) exhibit the same behavior as ssh.
I can't tell for sure but I guess it's an interaction with the console
handling. The console which has been opened by the service likely
gets a console event of type CTRL_LOGOFF_EVENT. We have special code
in our console handler routine which deals with CTRL_LOGOFF_EVENT by
examining if the process has a visible window station and if not,
it doesn't send the SIGHUP, but this is not the case here. The open
console is obviously running in a visible window station, so it
gets a SIGHUP.
> Does the cygwin system offer up a parameter to select what the cygwin
> app conforms to
No, there's nothing like that available. As a test and potential
workaround for now, could you try running the ssh process so that
it's disconnected from its controlling tty? For instance, like
this:
$ setsid ssh $parameters < /dev/null >& /var/log/myssh.out
Maybe we have to rethink our CTRL_LOGOFF_EVENT strategy, assuming
my thoughts are basically correct.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -