bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unfinished command executed when TTY is closed


From: Steve Simmons
Subject: Re: unfinished command executed when TTY is closed
Date: Wed, 17 Dec 2014 15:16:53 -0500

Advance apologies if I'm misunderstanding, but the described bug looks like 
reasonable behavior to me.

When a ssh connection drops, which side notices and when depends on the I/O 
being done on either side, the state of any keepalive settings, and the 
timeouts involved. If there's a long time between keepalives and the session is 
not generating I/O on the server side, I've seen sequences like this:

From host A, ssh via wireless to host B.
Start command on host B which does not generate network I/O.
Abrupt (unplanned) wireless connection lost on host A.

In such a case, host B does not yet know the connection has dropped because 
there is no network activity going on between host A and host B. So it will 
happily complete the job running on B, then disconnect when the shell on B 
attempts to send out the next command prompt and it fails. Host A may have 
noticed the drop well before this, as the user may have attempted type-ahead 
after the drop or because the ethX interface is lost completely when wireless 
is lost.

Steve


On Dec 17, 2014, at 10:54 AM, Chet Ramey <address@hidden> wrote:

> On 12/17/14, 8:34 AM, Jiri Kukacka wrote:
> 
>> I understand that this is due to handling EOF from closed TTY as \n, thus
>> executing the command, and this is standard behavior of readline, but I
>> think the problem is quite serious, so I have to fix it, and I hope that
>> you would like this to have fixed as well.
>> 
>> So, my current suggested fix is attached bellow (created for Bash 4.2),
>> thanks for any comments to it.
> 
> I would be interested in knowing what happens when the existing code is
> executed.  In bash-4.2/readline-6.2, rl_getc returns READERR if read(2)
> returns -1/errno!=EINTR and readline returns immediately without adding
> a newline.  It may be that bash executes a command that does not end in
> a newline, but in this case it doesn't seem like the code you modified
> should be executed.
> 
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]