Why is running an invalid process with '&' closes the terminal?

Question

When running, for example, a& in bash, the terminal window closes, where I would expect a new process to start followed by an error message (similar to, for example, grep &).

What is causing this behavior? Is it intentional?

edit: as requested,

yuvalw@UX410UQK:~$ echo $-
himBH

I also tried opening another bash in bash to get additional output. My input is bash followed by a& and a few new lines:

yuvalw@UX410UQK:~$ bash
yuvalw@UX410UQK:~$ a&
[1] 15323
yuvalw@UX410UQK:~$ exit
yuvalw@UX410UQK:~$ a: command not found

yuvalw@UX410UQK:~$

here calling a& again will close the terminal window.

edit2: more echos

yuvalw@UX410UQK:~$ echo "$BASH_VERSION $SHELLOPTS $BASHOPTS"
4.3.48(1)-release braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor checkwinsize:cmdhist:complete_fullquote:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:progcomp:promptvars:sourcepath

trap:

yuvalw@UX410UQK:~$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU

type exit:

yuvalw@UX410UQK:~$ type exit
exit is a shell builtin

PROMPT_COMMAND (empty):

yuvalw@UX410UQK:~$ echo $PROMPT_COMMAND

PS1:

yuvalw@\UX410UQK:~$ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$

edit 3: Opening a new terminal it doesn't seem like this happens, and I can run a& just fine, but after cding around for a bit the issue returns. In both cases the command_not_found_handle looks the same.

yuvalw@yuvalw-UX410UQK:~$ type command_not_found_handle

command_not_found_handle is a function
command_not_found_handle () 
{ 
    if [ -x /usr/lib/command-not-found ]; then
        /usr/lib/command-not-found -- "$1";
        return $?;
    else
        if [ -x /usr/share/command-not-found/command-not-found ]; then
            /usr/share/command-not-found/command-not-found -- "$1";
            return $?;
        else
            printf "%s: command not found\n" "$1" 1>&2;
            return 127;
        fi;
    fi
}

Answer 1

That was a bug in bash, fixed in 4.4.

If you have the command_not_found_handle() hook defined (which is invoked when a command is not found), bash puts it in foreground even if the not found command was started in background.

Then, depending on timing, if the shell reads the command line from the tty device after the command_not_found_handle was put in foreground, that read() would return with an EIO error as happens when a background process reads from a terminal device and ignores the SIGTTIN signal.

bash would treat that as end of file on user input as if you had pressed Ctrl+D

One can reproduce the problem by doing:

$ command_not_found_handle() { sleep 20; }
$ a &
$ x

Even if the first read() succeeds because it's started before the command_not_found_handle is put in foreground, the second and subsequent reads after you press x will fail and cause the shell to exit.

With the default command_not_found_handle shipped on Ubuntu,

$ a & true &

Also causes the shell to exit as the SIGCHLD upon true returning interrupts the first read() and causes a second one to be started with the handler still running in foreground.

In the general case however, the bug seems unlikely to trigger as the shell also puts itself in foreground before writing its prompt, so the command_not_found_handle has to put itself in foreground (do the tcsetpgrp()) at the right moment (after the main shell process puts itself in foreground and before it starts reading from the tty device).

That was fixed in April 2015, with this commit (4/23 entry in CWRU.log) following a report to a related problem by Valentin Bajrami.