Hi!
For those who have not noticed yet...
A new version of vzctl was released which fixes this issue:
http://bugzilla.openvz.org/show_bug.cgi?id=1812#c7
Thanks for all help!
Michael
On 15 mar, 17:03, Chet Ramey wrote:
> > > So vzctl is running bash in a pty and talking to it that way?
>
> >
> Michael Kalisz opened a bug report with the openvz group.
And the OpenVZ guys have just released a patch:
http://bugzilla.openvz.org/show_bug.cgi?id=1812
I've tested it and the problem is solved. Thanks again for the help and
of course all the efforts you put in this project!
--
Henk van de
> That's what I got, and the strace points the finger at vzctl. It looks
> like a bug in vzctl that was masked by bash-4.1 and previous versions.
Thanks for the investigation. It is always difficult when two packages
are working together and changing one of them breaks the cooperation :-).
> Mic
> > So vzctl is running bash in a pty and talking to it that way?
>
> For the exact details I'll point to the OpenVZ guys :-). It is an OS
> virtualization patch for the kernel. With it you can run virtual servers
> which are isolated from each other.
The answer to my question was "yes."
> What
> So vzctl is running bash in a pty and talking to it that way?
For the exact details I'll point to the OpenVZ guys :-). It is an OS
virtualization patch for the kernel. With it you can run virtual servers
which are isolated from each other.
The vzctl enter number is used on the physical server
On 8 mar, 22:36, Chet Ramey wrote:
> On 3/8/11 10:04 AM, gnu.bash.bug wrote:
>
> > Running "strace -fvzctlenter 152 " shows:
>
> Sovzctlis running bash in a pty and talking to it that way?
>
> I'd be interested in seeing what interrupted the select/read/write/
> sigprocmask system calls in both pr
On 3/14/11 5:15 AM, Henk van de Kamer wrote:
>> I'd be interested in seeing what interrupted the select/read/write/
>> sigprocmask system calls in both processes.
>
> What exactly do you want. A full strace report?
>
> I'm trying to find the difference between 4.1.9 and 4.2.0 which causes
> this
On 3/8/11 10:04 AM, gnu.bash.bug wrote:
> Running "strace -f vzctl enter 152 " shows:
So vzctl is running bash in a pty and talking to it that way?
I'd be interested in seeing what interrupted the select/read/write/
sigprocmask system calls in both processes.
Chet
--
``The lyf so short, the cr
Running "strace -f vzctl enter 152 " shows:
[pid 19449] rt_sigaction(SIGTSTP, {0x80e0b10, [], SA_RESTORER,
0x9f8e98}, {0x1, [], SA_RESTORER, 0x9f8e98}, 8) = 0
[pid 19449] rt_sigaction(SIGTSTP, {0x1, [], SA_RESTORER, 0x9f8e98},
{0x80e0b10, [], SA_RESTORER, 0x9f8e98}, 8) = 0
[pid 19449] rt_sigaction
> That's not an unreasonable assumption, but it needs to be verified, and
> nobody has been able to provide solid evidence that bash is at fault.
If one thing is changing and it breaks something, it is very logical to
start the investigation there. I don't say that Bash is the fault,
because it co
On 3/5/11 9:50 AM, Henk van de Kamer wrote:
>> This is normal. Readline is trying to read input.
>
> May be normal, but then please explain why Bash 4.1 patchlevel 009 works
> and Bash 4.2 patchlevel 6 don't. If I downgrade the virtual container it
> works again. So the only change is Bash and un
On Fri, Mar 04, 2011 at 08:59:30AM +0100, Henk van de Kamer wrote:
> > That says nothing about what the child process does.
>
> Correct, but that is as far as I get with my knowledge :-).
Please enlighten yourself as on how to trace child processes,
by reading strace(1) manual page.
--
ldv
p
> This is normal. Readline is trying to read input.
May be normal, but then please explain why Bash 4.1 patchlevel 009 works
and Bash 4.2 patchlevel 6 don't. If I downgrade the virtual container it
works again. So the only change is Bash and until proven otherwise that
is in my humble opinion the
Any hints how to troubleshoot this?
I tried to change the root shell "to /bin/bash -v" but did not get any
more output...seems as as the shell starts but hangs before displaying
the prompt.
The strange thing is that it works while logging in using ssh to the
same container.
//Michael
On 3/4/11 4:50 AM, gnu.bash.bug wrote:
> I've noticed the same behavior
>
> while it works with the original redhat/cenos (3.2.25) shell it will
> not work with 4.2.6
>
> Example:
>
> # vzctl enter 152
> will just hang.
>
> Attaching to the bash process within the container shows the follo
I've noticed the same behavior
while it works with the original redhat/cenos (3.2.25) shell it will
not work with 4.2.6
Example:
# vzctl enter 152
will just hang.
Attaching to the bash process within the container shows the following
backtrace:
(gdb) bt
#0 0x00f297f2 in _dl_sysinfo_int80
> That says nothing about what the child process does.
Correct, but that is as far as I get with my knowledge :-). I've also a
strace with Bash 4.1 patchlevel 9 around this point and that goes as
follows:
...
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr
Henk van de Kamer writes:
> The proces hangs. When combined with strace I get the following:
>
> ...
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x2b65860859d0) = 29577
> close(3)= 0
> close(7)
> While strace shows a great deal, a stack traceback from gdb would be
> more informative. Attach to the running bash process with gdb, and
> run the `where' command.
This is way over my head :-). I've never used gdb and although the vzctl
commands executes bash, I have no idea if and how you can
On 3/2/11 8:38 AM, Henk van de Kamer wrote:
> Bash Version: 4.2
> Patch Level: 6
> Release Status: release
>
> Description:
> Bash 4.1 patchlevel 9 works but when an OpenVZ container is upgraded to Bash
> 4.2 patchlevel 6 you can't login through the physical node with the vzctl
> enter command.
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba
21 matches
Mail list logo