after upgrading to 4.2 bash stopped working inside a OpenVZ container
Bug #732322 reported by
NIXin
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenVZ Tools |
Fix Released
|
High
|
|||
vzctl (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Hardy |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: bash
Using openvz on my Debian Squeeze host.
Inside a Ubuntu Natty containter (guest), after upgrading bash package from 4.1-2ubuntu5 to 4.2-0ubuntu2 - bash stops working.
This disables the
"vzctl enter VEID" command, as it chroots the virtual server and runs /bin/bash.
I've debugged this by downgrading back to 4.1-2 by running "vzctl exec VEID apt-get install bash/maverick" - after which "vzctl enter" works again.
I have not tested whether SSH bash login works or with bash 4.2 on a Debian Unstable guest.
I have reproduced the bug on two different host machines though. Not sure what is the cause of the bug.
Related branches
Changed in openvz-tools: | |
importance: | Unknown → High |
status: | Unknown → Fix Released |
To post a comment you must log in.
Created attachment 1429
strace sessions of vzctl enter
Hi!
Problem:
When running "vzctl enter <VEID>" the command will hang with latest
version of bash i.e 4.2.7 ( happens with all 4.2.x versions )
I first thought this was bash bug and filed a report to the maintainer
of bash (Chet Ramey) but got back the response below which indicates this
might be a bug in vzctl instead,
Let me know if you need any more information.
There is also a thread discussing this issue at:
https:/ /groups. google. com/group/ gnu.bash. bug /groups. google. com/group/ gnu.bash. bug/browse_ thread/ thread/ 0be5df8f41c8b88 c#
https:/
//Michael
> Hi Chet! strace/ bash_working/ bash_working. log vzctl enter 152 strace/ bash_not_ working/ bash_not_ working. log ---strace( 23230)- --vzctl( 23231)- --vzctl( 23232)- --bash( 23233)
>
> I run 3 different strace sessions (see attached file)
>
> 1. A working session (bash 3.2.25)
>
> # strace -ff -o /tmp/bash_
>
> 2. A failing session (bash 4.2.7):
>
> # strace -ff -o /tmp/bash_
> vzctl enter 152
>
> for the failing session pstree shows:
>
> bash(23067)
I suspect this is a bug in vzctl that was masked by bash-4.1 and previous
versions.
The only change of any significance here is that bash-4.1 closed file
descriptors 3-20 at startup. That's a bug; you can't close fds out
from under libraries like that. This caused mysterious crashes on Mac
OS X, for example when running bash as a login shell under iTerm.
Bash-4.2 sets the fds to close-on-exec instead.
The problem is that vzctl plays fast and loose with file descriptors.
It leaves read and write ends of pipes open in the child process it
forks to exec bash when it uses the other ends internally to communicate
with that child through the pty it opens as the controlling terminal.
The big difference between the non-working and working versions is that
bash-4.2 inherits file descriptors 3, 7, 9, and 10 and leaves them open,
where bash-4.1 closed them.
This results in the the process group that bash-4.2 is using being
orphaned, which makes read() return EOF and the kernel send SIGHUP and
SIGCONT to bash. This is consistent with the strace output.
You can test this by changing shell.c to call close(i) instead of ON_EXEC( i) around like 541. That's just to prove vzctl has
SET_CLOSE_
a bug, however -- I'm not going to revert that change.
Keep in mind that I haven't looked at the vzctl source code, and so don't
have any patches for it. Somehow, though, the file descriptors that
get closed in process 23231 after forking 23232 (in the bash-not-working
set of traces, fds 3,7,9,10) need to get closed in 23233 after 23232 forks
it and before it execs bash.
Let me know how it goes. If you can make the right changes to vzctl and
that fixes the problem, so much the better.