Running a non-existing command in the background causes exit

Bug #241331 reported by Richard G. Clegg
This bug affects 3 people
Affects Status Importance Assigned to Milestone
bash (Ubuntu)

Bug Description

Binary package hint: gnome-terminal

In Ubuntu 8.04, running a command which does not exist can sometimes cause an exit command. Here is an example cut and pasted when gnome-terminal is set to "stay open on exit".

richard@sepulchrave:~$ gedit test &
[1] 13336
richard@sepulchrave:~$ gdit test &
[2] 13340
richard@sepulchrave:~$ exit

Other times the exit will not happen but the command will return an Exit 127 status.

richard@sepulchrave:~$ gdit test &
[1] 13403
richard@sepulchrave:~$ bash: gdit: command not found

[1]+ Exit 127 gdit test
richard@sepulchrave:~$ gdit test &
[1] 13405
richard@sepulchrave:~$ exit

Package is
  Installed: 2.22.1-0ubuntu2
  Candidate: 2.22.1-0ubuntu2
  Version table:
 *** 2.22.1-0ubuntu2 0
        500 hardy/main Packages
        100 /var/lib/dpkg/status

Revision history for this message
Richard G. Clegg (richard-richardclegg) wrote :

Sorry -- looking further I think this may be an issue with command_not_found_handler not gnome-terminal at all.

Revision history for this message
Dariusz B. Tefelski (tefelski) wrote :

I confirm.

When you try using xterm - it behaves alike, however it more frequently works without crash - it prints new pid and after a while it prints bash: gdit: command not found. It does not return to prompt - you need to press enter and then it prints Exit 127.

 gdit &
[1] 6733
darek@spectrum:~$ bash: gdit: polecenie nieodnalezione

[1]+ Exit 127 gdit
darek@spectrum:~$ gdit &

I found that gnome-terminal works sometimes without crash - if you try run some non-existent commands without ampersand and then try it with ampersand it does not crash.

Maybe it is some buffer issue? And I have seen 'exit' in closing xterm.

Revision history for this message
Yung-Chin Oei (yungchin) wrote :

Sort of to my surprise, I managed to reproduce this. I entered "does not exist &" at the bash prompt, and the shell exited. On opening a new Gnome terminal, I was quite surprised to find that that line made it into my bash history (which suggests it's a fairly clean exit). I had another succes with "pester the system &". As reported above, the shell exit does not occur every time.

Changed in bash:
status: New → Confirmed
Revision history for this message
Yung-Chin Oei (yungchin) wrote :

I had a look at the bash code that handles this, but there's so much conditional forking and all... really way over my head for now.

As a guidance for setting the importance of this bug (to whomever is allowed to do that), I'd say it is of low importance. I just played around a bit in gdb, and the shell will refuse to exit when there are stopped jobs, so you won't lose work to this bug (as mentioned in my previous comment: you even keep your command history).

Attached is the console output of that playing around.

Revision history for this message
Yung-Chin Oei (yungchin) wrote :

Sorry: clarification to the file just appended with the previous comment:
I didn't type the line that says "exit", it appears as a result of trying "cats &". This is the manifestation of the bug...

Revision history for this message
sasha1024 (sasha1024) wrote :

The same happends to me in Konsole (Kubuntu 10.4 alpha, Konsole 2.4.1, GNU bash version 4.1.0(1)-release)

Revision history for this message
Richard G. Clegg (richard-richardclegg) wrote :

This seems to not happen in later versions of Ubuntu. I guess it got patched.

Revision history for this message
Bill Zaumen (zaumen) wrote :

I just ran into this bug and there seems to be a path-name dependency on it showing up. In some directories it happens consistently, making it a real annoyance. If it is in fact dependent on the length of a pathname, or the form of a directory name, that might be useful in locating the cause.

Here are the commands I used (my home directory is /home/wtz ):

cd ~
mkdir -p Projects
cd Projects
mkdir Foo
cd Foo
mkdir Test
cd Test
mkdir org
cd org
mkdir bzdev
cd bzdev
mkdir ejws
foo &
[crashes? - may be intermittent ]
cd ~/Projects
cd Foo
cd Test/org/bzdev
foo &
[error message ending with foo: command not found]
cd ~
cd Projects
cd Foo
cp -r Test Test-Test
cd Test-Test/org/bzdev
foo &
[gnome terminal disappears]

It acts like having the '-' in the directory name is related to the problem, but it could just be the path-name length, directory-name length, etc. In a subdirectory of a directory that has a '-' in the file name, the bug seems to always occur. I'm using a fairly recent version of Ubuntu (10.10) on a 2-core, Intel i3 with two threads per core.

Also, it seemed there was a dependency on whether the directory the command was run with had files or subdirectories in it (which needs to be verified, of course).

Revision history for this message
Richard G. Clegg (richard-richardclegg) wrote :

It seems this has reappeared after some absence. Don't know if bash is at fault. Anyway, in an xterm or gnome-terminal, typing

made_up_command &

Will often but not always cause the terminal to vanish which is extremely annoying!

Revision history for this message
Jaakov (jaakov-deactivatedaccount) wrote :

I confirm the bug presence on Ubuntu Precise + some upstream packages.
bash version: 4.2-2ubuntu2.1
It is 100% repeatable and terribly annoying.
It is dependent on the path length. How to reproduce on my system:
1. Make sure that you have /usr/share/doc/texlive-doc/latex/computational-complexity, or whatever other long path, e.g., by installing texlive-science-doc version 2012.20120611-2.
2. Change into /usr/share/doc/texlive-doc/latex/computational-complexity.
3. Assuming some nonexistant command qqq, type
qqq &
into the bash shell and press Enter.
4. Observe that the bash closes. It should not.

Revision history for this message
Richard G. Clegg (richard-richardclegg) wrote :

Good catch. I confirm that path length does seem to be an issue here. This bug has been around since 2008 now -- it's very annoying.

Revision history for this message
Jaakov (jaakov-deactivatedaccount) wrote :

The bug does not occur on Debian with
bash version 4.2+dfsg-0.1+deb7u3,
xterm version 278-4
and the de_DE.utf8 LANG and LC_... .
So, whoever has a chance to look for the error, take the diff...

Revision history for this message
Jaakov (jaakov-deactivatedaccount) wrote :

I found out that though the bug is pretty reproducible on long path lengths, for short path lengths, the bug is sometimes reproducible, but sometimes not.
Test case:
1. Open an xterm with a bash.
2. Make sure that the command q is not present on your system.
3. cd / [Enter]
4. q & [Enter]

Continue doing 4. until your bash exits. I needed 66 attempts for the root directory "/" and command "qqq". With the command "q" it was 51 attempts.
The tested locale is de_DE.UTF-8 for LANG, LC_..., and LANGUAGE on ubuntu,
bash has version 4.3-7ubuntu1.3,
xterm has version 297-1ubuntu1.
Since the behavior is not deterministic on the user input, it looks like a memory corruption issue or a race. Any help?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.