This patch mostly worked, however the process in the foreground doesn't
always redraw. I threw an strace on a less to see what was going on and
this is what I saw:
Successful refresh:
--- SIGWINCH (Window changed) @ 0 (0) ---
rt_sigaction(SIGWINCH, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo
...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo
...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(2, TIOCGWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
write(1, "\33[H\33[J\33[H# /etc/services:\n# $Id:"..., 1023) = 1023
gettimeofday({1382552680, 471242}, NULL) = 0
write(1, " # TCP port service "..., 48) = 48
read(3, 0x7fff1153005f, 1) = ? ERESTARTSYS (To be restarted)
--- SIGWINCH (Window changed) @ 0 (0) ---
rt_sigaction(SIGWINCH, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo
...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo
...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(2, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
write(1, "\33[H\33[J\33[H# /etc/services:\n# $Id:"..., 992) = 992
read(3,
Unsuccessful refresh:
--- SIGWINCH (Window changed) @ 0 (0) ---
rt_sigaction(SIGWINCH, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo
...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo
...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(2, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
write(1, "\r\33[K:\33[K", 8) = 8
read(3,
It seems like that in some cases, the initial SIGWINCH with the resize
(ws.ws_row++) isn't happening, so the second SIGWINCH resize
(ws.ws_row--) doesn't actually change the window size, so no refresh is
done. I also ran an strace on the hostnode on the "vzctl console"
command and all of the ioctl calls to resize the tty are happening:
rt_sigaction(SIGWINCH, {0x403610, [WINCH], SA_RESTORER|SA_RESTART,
0x7fa78b4fe960}, {SIG_DFL, [], 0}, 8) = 0
ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(5, TIOCSWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(5, TIOCSWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
write(2, "Attached to CT 1033892 (ESC . to"..., 41) = 41
So it looks like vzctl is making the right calls and they are returning
successfully, but the SIGWINCH never arrives at the foreground process.
Any idea what might be happening here? Worse comes to worse I can just
add some code to the patch that checks to make sure the winsize has
actually changed before changing it back...
On 10/22/2013 05:57 PM, Kir Kolyshkin wrote:
On 10/22/2013 12:53 PM, Dan Bassett wrote:
First off, we've got two openvz environments running. Both are on CentOS6, our
production environment is on vzctl 4.2.1 and our test is on 4.5.1. With that
stuff out of the way...
If I start a console on a container using vzctl, then detach, then start that
same console again, the console remains blank. This seems to be the default
(and possibly intended) behavior, but it seems kind of lame. If I (or more
importantly, a user) has left something like a vi session running and they get
disconnected and then come back, the vi session doesn't redraw when the console
gets reattached. In most cases, our users aren't clueful enough to deal with
this situation and they just assume that something is broken.
This is what Ctrl-L in vim is for.
Alternatively, you can use ESC ! to kill everything running on current
console (so-called SAK,
http://en.wikipedia.org/wiki/Secure_attention_key) so it will revert
to show usual getty screen (if configured). In the first vzctl console
implementation we did SAK on exit, so every vzctl console started with
a fresh session (if init is configured to run getty on it).
Unfortunately, some programs got attached to /dev/console so we
removed SAK on exit.
I have found that if I enter the container or attach on some other tty and
cause a SIGWINCH to be generated and sent to the foreground process in the tty
in question, it happily redraws itself. This has worked for vi, emacs, less
and bash so far (and I expect other to work as well).
vzctl console sends SIGWINCH upon attaching. The problem is neither
bash nor vim react to it, probably because the window size is still
the same. But if you do vzctl console, run vim (or bash), detach,
change the xterm size and run another vzctl console, you will see that
vim/bash redraws.
My crappy way around this is to use stty inside the container to get the
number of columns, then set the number of columns to one less than that value,
then set it back to the original value. Oddly, just using kill to send a
SIGWINCH to the foreground process doesn't always work. Unfortunately, I
haven't come up with a good way of causing this action to happen when a user
connects with vzctl console...
The only thing I can think of is a dirty hack -- on attach, send one
SIGWINCH with a different (bogus) window size, then another one with a
proper size. Same crappy way as you found, just automated.
Attached patch does just that -- and it works for me. Please give it a
try and report back.
Nevertheless, this looks a big ugly to me.
Anyway, before everybody says "Just use ssh!", I should make it clear that
connecting with ssh in our environment isn't always possible. We're using openvz to
teach systems administration, so we start with a container that doesn't have any
networking set up or the sshd package installed. Therefore, the only option is to have
students connect on the consoles until they have networking set up.
Well, in fact neither vzctl console (nor vzctl enter) were meant to be
used this way. vzctl console is more like a way to see how system
boots (because init writes to the console), vzctl enter is a backdoor. So
So finally my question. Am I missing something here, or is this just the way
it is? I wanted to make sure I wasn't missing something obvious before I
emailed the developer list to ask if anything could be done. Thanks!
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
