<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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:<br>
<br>
Successful refresh:<br>
<br>
--- SIGWINCH (Window changed) @ 0 (0) ---<br>
rt_sigaction(SIGWINCH, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, 8) = 0<br>
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0<br>
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon
-echo ...}) = 0<br>
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon
-echo ...}) = 0<br>
ioctl(1, TIOCGWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
ioctl(2, TIOCGWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
write(1, "\33[H\33[J\33[H# /etc/services:\n# $Id:"..., 1023) = 1023<br>
gettimeofday({1382552680, 471242}, NULL) = 0<br>
write(1, " # TCP port service "..., 48) = 48<br>
read(3, 0x7fff1153005f, 1) = ? ERESTARTSYS (To be
restarted)<br>
--- SIGWINCH (Window changed) @ 0 (0) ---<br>
rt_sigaction(SIGWINCH, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, 8) = 0<br>
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0<br>
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon
-echo ...}) = 0<br>
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon
-echo ...}) = 0<br>
ioctl(1, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
ioctl(2, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
write(1, "\33[H\33[J\33[H# /etc/services:\n# $Id:"..., 992) = 992<br>
read(3, <br>
<br>
<br>
Unsuccessful refresh:<br>
<br>
--- SIGWINCH (Window changed) @ 0 (0) ---<br>
rt_sigaction(SIGWINCH, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, {0x414a50, [WINCH], SA_RESTORER|SA_RESTART,
0x7f50b1e78960}, 8) = 0<br>
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0<br>
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon
-echo ...}) = 0<br>
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon
-echo ...}) = 0<br>
ioctl(1, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
ioctl(2, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
write(1, "\r\33[K:\33[K", 8) = 8<br>
read(3,<br>
<br>
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:<br>
<br>
rt_sigaction(SIGWINCH, {0x403610, [WINCH], SA_RESTORER|SA_RESTART,
0x7fa78b4fe960}, {SIG_DFL, [], 0}, 8) = 0<br>
ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
ioctl(5, TIOCSWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
ioctl(5, TIOCSWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0,
ws_ypixel=0}) = 0<br>
write(2, "Attached to CT 1033892 (ESC . to"..., 41) = 41<br>
<br>
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...<br>
<br>
On 10/22/2013 05:57 PM, Kir Kolyshkin wrote:
<blockquote cite="mid:526702E6.4070701@openvz.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 10/22/2013 12:53 PM, Dan Bassett
wrote:<br>
</div>
<blockquote
cite="mid:C4D8F4B8-9F63-4861-94E4-C18A38BB8BC9@oreillyschool.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
This is what Ctrl-L in vim is for.<br>
<br>
Alternatively, you can use ESC ! to kill everything running on
current console (so-called SAK,
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/Secure_attention_key">http://en.wikipedia.org/wiki/Secure_attention_key</a>)
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. <br>
<br>
<br>
<blockquote
cite="mid:C4D8F4B8-9F63-4861-94E4-C18A38BB8BC9@oreillyschool.com"
type="cite">
<pre wrap="">
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).</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:C4D8F4B8-9F63-4861-94E4-C18A38BB8BC9@oreillyschool.com"
type="cite">
<pre wrap=""> 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...</pre>
</blockquote>
<br>
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.<br>
<br>
Attached patch does just that -- and it works for me. Please give
it a try and report back.<br>
<br>
Nevertheless, this looks a big ugly to me.<br>
<br>
<blockquote
cite="mid:C4D8F4B8-9F63-4861-94E4-C18A38BB8BC9@oreillyschool.com"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
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 <br>
<br>
<blockquote
cite="mid:C4D8F4B8-9F63-4861-94E4-C18A38BB8BC9@oreillyschool.com"
type="cite">
<pre wrap="">
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!
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@openvz.org">Users@openvz.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openvz.org/mailman/listinfo/users">https://lists.openvz.org/mailman/listinfo/users</a>
</pre>
</blockquote>
</body>
</html>