Re: bash randomly logs out on VT / serial console

[Russell King]

On Tue, Jan 03, 2017 at 09:03:52AM +0000, Russell King wrote:
> On Mon, Jan 02, 2017 at 02:06:01PM -0500, Chet Ramey wrote:
> > On 1/2/17 6:09 AM, Russell King wrote:
> > > On Sun, Jan 01, 2017 at 09:14:45PM -0500, Chet Ramey wrote:
> > >> On 1/1/17 4:01 PM, rmk@armlinux.org.uk wrote:
> > >>> Bash Version: 4.3
> > >>> Patch Level: 30
> > >>> Release Status: release
> > >>>
> > >>> Description:
> > >>>         Running:
> > >>>                 while :; do s=$(sleep .005 | cat); echo $s; done | uniq
> > >>>         in a login shell on a virtual terminal or serial console results
> > >>>         in the shell randomly logging out after ^C.
> > >>
> > >> I believe this is fixed in bash-4.4.
> > > 
> > > Thank you for your reply.
> > > 
> > > However, while testing bash-4.4 with the five additional patches (bringing
> > > it to 4.4.5) shows that it is not fixed in bash-4.4 - see below.  The line
> > > from __tty_check_change() is from the debug I added to the kernel, which
> > > shows that the reason for the EIO error is because the tty pgrp doesn't
> > > match the process' pgrp.
> > 
> > OK.  I can't reproduce it on Fedora 25.
> 
> Digging into why Fedora doesn't show it comes down to distro choices.
> 
> Fedora ships util-linux login, which does this when starting the shell:
> 
> setsid()                = 14301
> open("/dev/pts/4", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
> ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> fcntl64(3, F_GETFL)     = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
> fcntl64(3, F_SETFL, O_RDWR|O_LARGEFILE) = 0
> close(0)                = 0
> close(1)                = 0
> close(2)                = 0
> dup2(3, 0)              = 0
> dup2(3, 1)              = 1
> dup2(3, 2)              = 2
> close(3)                = 0
> ioctl(0, TIOCSCTTY, 1)  = 0
> rt_sigaction(SIGINT, {SIG_DFL, [INT], SA_RESTART}, {SIG_IGN, [], 0}, 8) = 0
> setuid32(0)             = 0
> chdir("/root")          = 0
> execve("/home/rmk/bash/bash-4.4/build-pristine/bash", ["-bash"], [/* 8 vars 
> */]) = 0
> 
> This has the effect that bash sees that the existing PGRP is the same
> as the PID - so bash's "original_pgrp" and "shell_pgrp" end up as the
> same thing.
> 
> Debian and Ubuntu ship shadow-utils login, which makes no calls to
> setsid, no TIOC*PGRP calls, no TIOCSCTTY calls.  It also makes no
> attempt to open the tty itself, using the stdin/stderr supplied
> to print it's prompts and read the login name and password.
> 
> This results in bash's "original_pgrp" being the PID of the login
> process, and "shell_pgrp" the PID of the top level bash - and that
> is a requirement for triggering the bug.
> 
> So, systems using util-linux login will not show this bug.  Systems
> using shadow-utils login do show the bug.

Sorry for the third mail since you last responded.

Having built the util-linux login on one of my Ubuntu boxes, when
logging in using the shadow-utils login, with the bash shell printing
its internal pgrp state in initialize_job_control() via the handy
function already provided:

TRACE: pid 6112: original_pgrp = 6076 shell_pgrp = 6112 terminal_pgrp = 6112
TRACE: pid 6112: tcgetpgrp(255) -> 6112, getpgid(0) -> 6112

With the util-linux flavour of login (used by Fedora):

TRACE: pid 6217: original_pgrp = 6217 shell_pgrp = 6217 terminal_pgrp = 6217
TRACE: pid 6217: tcgetpgrp(255) -> 6217, getpgid(0) -> 6217

Note - util-linux login is not offered as an alternative on debian or
ubuntu installations - this is a custom modification.

The bash problem is unreproducable when the util-linux login flavour
is used due to original_pgrp == shell_pgrp, which effectively hides the
bug.

-- 
Russell King