X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Message-ID: <4B8BEACA.4010003@towo.net>
Date: Mon, 01 Mar 2010 17:26:50 +0100
From: Thomas Wolff <towo AT towo DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: terminals getting killed on parent's termination
References: <201002261446 DOT o1QEki2k024924 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net> <416096c61002261229j31f92387u8b8e3e9b716cb131 AT mail DOT gmail DOT com>
In-Reply-To: <416096c61002261229j31f92387u8b8e3e9b716cb131@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 26.02.2010 21:29, Andy Koppe wrote:
> Thomas Wolff wrote:
>    
>> In general, a GUI application started in the background, like a terminal,
>> should detach itself from its parent process so that it survives if the
>> parent is terminated.
>>      
> Says who?
Common practice in Unix/Linux/X environments. And user expectation that 
an interactive session (which may e.g. contain an editing session with 
unsaved changes...) should not be aborted by an unrelated event.

> You can always invoke it with setsid or some such to detach it.
>    
Which is not common user practice when starting a terminal, though.

>> I've noticed the following sometimes surprising inconsistencies about this:
>>
>> mintty
>>         xterm&
>>         mintty&
>>         Close/Alt-F4
>>         ->  dialog "Processes are running in session. Exit anyway?"
>>         OK
>>         ->  xterm remains
>>         ->  mintty is killed
>> xterm
>>         xterm&
>>         mintty&
>>         Close/Quit
>>         ->  xterm remains
>>         ->  mintty is killed
>>      
> Mintty has default handling for SIGHUP, i.e. it exits.
Actually (another topic but related) mintty has a great feature here: it 
passed the SIGHUP to its client application and if that application 
catches and handles the SIGHUP, mintty does *not* exit. This enables an 
application to be embedded into mintty as a terminal container and 
implement some reasonable "Really exit?" behaviour with the option not 
to exit.
I suspect though, that this feature might not be on purpose since the 
semantics of SIGHUP would be slightly tweaked here. Anyway, it's very 
useful, so I'd like to ask to please make it a defined feature to rely 
on (and I'll improve mined to handle this more properly...).

> Same for rxvt. Xterm presumably chooses to ignore it.
>
>    
>> mintty
>>         xterm&
>>         mintty&
>>         exit
>>         ->  all child terminals remain
>> xterm
>>         xterm&
>>         mintty&
>>         exit
>>         ->  all child terminals remain
>>      
> I don't understand why there isn't a SIGUP in these cases.
>
>    
>> cygwin console
>>         xterm&
>>         mintty&
>>         exit/Alt-F4
>>         ->  console hangs
>>      
> It's not really hanging; it's just waiting for xterm to finish. Xterm
> is linked as a console subsystem program, which means at startup it
> attaches to its parent's console (or opens its own if there isn't
> one). Consoles stay open as long as there's at least one process
> attached to them.
>
> Mintty, meanwhile, is a GUI subsystem program, which means it doesn't
> attach to or open a console.
>    
Thanks for the interesting technical background. From the user 
experience point of view, however, it doesn't make a difference how the 
terminal is implemented if an important active session just suddenly 
shuts down... Especially if it may happen or not in various inconsistent 
combinations which cannot be predicted without remembering the technical 
background.

>>         Close
>>         ->  mintty remains
>>         ->  xterm is killed
>>      
> When a console is closed, Windows kills all processes attached to it.
>
>    
>> Also, mintty can be protected from being killed by spawning it with
>> (mintty&)
>> while xterm, spawned this way from a cygwin console, still gets killed.
>>      
> Yep, doing that doesn't break the console attachment.
>    
So maybe this would be an enhancement item for the cygwin dll, that an 
application that detaches from its parent tty in Unix/Linux terms (don't 
remember the details how to do this) should also be detached from the 
console, if possible?

Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple