[Users] vzctl console behavior

[Dan Bassett]

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 at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20131023/3fbfbf84/attachment.html>