Quoting Serge Hallyn (serge.hal...@ubuntu.com): > Quoting Dwight Engen (dwight.en...@oracle.com): > > Add a higher level console API that opens a tty/console and runs the > > mainloop as well. Rename existing API to console_getfd(). Use these in > > the python binding. > > > > Allow attaching a console peer after container bootup, including if the > > container was launched with -d. This is made possible by allocation of a > > "proxy" pty as the peer when the console is attached to. > > > > Improve handling of SIGWINCH, the pty size will be correctly set at the > > beginning of a session and future changes when using the lxc_console() API > > will be propagated to it as well. > > > > Refactor some common code between lxc_console.c and console.c. The variable > > wait4q (renamed to saw_escape) was static, making the mainloop callback not > > safe across threads. This wasn't a problem when the callback was in the > > non-threaded lxc-console, but now that it is internal to console.c, we have > > to take care of it. This is now contained in a per-tty state structure. > > > > Don't attempt to open /dev/null as the console peer since /dev/null cannot > > be added to the mainloop (epoll_ctl() fails with EPERM). This isn't needed > > to get the console setup (and the log to work) since the case of not having > > a peer at console init time has to be handled to allow for attaching to it > > later. > > > > Move signalfd libc wrapper/replacement to utils.h. > > Thanks. Resizing still doesn't work right for me, but it's not like > that's a regression, so I won't wait on that to push this. > > (I do want to spend a bit more time reading it in detail)
Hi Daniel, so Dwight's patch fixes window resize detection in lxc_console and even in console 0 (lxc-start's console) - with one exception: the setsid() prevents lxc_console from getting sigwinch. The setsid was there since the beginning in lxc_console(). My question is: what is the reason for it being there? When I remove it, window resizes are perfectly handled in the lxc console, and ctrl-c/z still work as expected. Is it to prevent the container console window from writing garbage to the containing window (as in the known su and sudo vulnerabilities)? Or do you think it can safely be removed? thanks, -serge ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel