[Users] vzctl console behavior

[Kir Kolyshkin]

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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20131022/63d29496/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.diff
Type: text/x-patch
Size: 889 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/users/attachments/20131022/63d29496/attachment.bin>