[libvirt] lxc: setsid() usage
Hi! Why is libvirt-lxc issuing a setsid() in lxcContainerSetupFDs()? To me it seems like a hack to have a controlling TTY if PID 1 is /bin/bash. If one runs a sysv init style distro (like Debian) in libvirt-lxc the setsid() has a major downside, when getty spawns a login shell on /dev/tty1 it cannot become the controlling tty. Hence, if one presses ctrl-c in such a session, the container will reboot. Interestingly it does not happen when a systemd distro is used. Maybe because systemd completely closes and reopens the TTY? Thanks, //richard
On Mon, Jun 22, 2015 at 04:40:37PM +0200, Richard Weinberger wrote:
Hi!
Why is libvirt-lxc issuing a setsid() in lxcContainerSetupFDs()? To me it seems like a hack to have a controlling TTY if PID 1 is /bin/bash.
I honestly can't remember the reason. It might have been to ensure we have separation from the libvirt_lxc session.
If one runs a sysv init style distro (like Debian) in libvirt-lxc the setsid() has a major downside, when getty spawns a login shell on /dev/tty1 it cannot become the controlling tty. Hence, if one presses ctrl-c in such a session, the container will reboot.
Is that problem due to the fact we call setsid(), or due to use calling ioctl(TIOCSCTTY) ?
Interestingly it does not happen when a systemd distro is used. Maybe because systemd completely closes and reopens the TTY?
I have a feeling it does close & reopen the tty, but i dunno if that has an impact on the ability to set the controlling tty ? Also note systemd uses the device via /dev/console, not /dev/tty1 and with 'container_ttys' we've told it not to use /dev/tty1 for gettys. So maybe it deals with /dev/console in a different way than it would if it were /dev/tty1 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Am 22.06.2015 um 16:51 schrieb Daniel P. Berrange:
On Mon, Jun 22, 2015 at 04:40:37PM +0200, Richard Weinberger wrote:
Hi!
Why is libvirt-lxc issuing a setsid() in lxcContainerSetupFDs()? To me it seems like a hack to have a controlling TTY if PID 1 is /bin/bash.
I honestly can't remember the reason. It might have been to ensure we have separation from the libvirt_lxc session.
Hm, can be.
If one runs a sysv init style distro (like Debian) in libvirt-lxc the setsid() has a major downside, when getty spawns a login shell on /dev/tty1 it cannot become the controlling tty. Hence, if one presses ctrl-c in such a session, the container will reboot.
Is that problem due to the fact we call setsid(), or due to use calling ioctl(TIOCSCTTY) ?
If I remove the TIOCSCTTY nothing changes. Without setsid() libvirt is unable to start the container at all. So, I fear you're right that it has something do to with the libvirt session.
Interestingly it does not happen when a systemd distro is used. Maybe because systemd completely closes and reopens the TTY?
I have a feeling it does close & reopen the tty, but i dunno if that has an impact on the ability to set the controlling tty ?
My TTY-fu is not strong enough to answer that question.
Also note systemd uses the device via /dev/console, not /dev/tty1 and with 'container_ttys' we've told it not to use /dev/tty1 for gettys. So maybe it deals with /dev/console in a different way than it would if it were /dev/tty1
This can also be. If I change Debian's getty to use /dev/console instead of /dev/tty1 it is still unable to spwan a controlling tty. Thanks, //richard
Am 23.06.2015 um 14:18 schrieb Richard Weinberger:
Am 22.06.2015 um 16:51 schrieb Daniel P. Berrange:
On Mon, Jun 22, 2015 at 04:40:37PM +0200, Richard Weinberger wrote:
Hi!
Why is libvirt-lxc issuing a setsid() in lxcContainerSetupFDs()? To me it seems like a hack to have a controlling TTY if PID 1 is /bin/bash.
I honestly can't remember the reason. It might have been to ensure we have separation from the libvirt_lxc session.
Hm, can be.
If one runs a sysv init style distro (like Debian) in libvirt-lxc the setsid() has a major downside, when getty spawns a login shell on /dev/tty1 it cannot become the controlling tty. Hence, if one presses ctrl-c in such a session, the container will reboot.
Is that problem due to the fact we call setsid(), or due to use calling ioctl(TIOCSCTTY) ?
If I remove the TIOCSCTTY nothing changes. Without setsid() libvirt is unable to start the container at all. So, I fear you're right that it has something do to with the libvirt session.
Found a way to deal with that. Patch is on the way. The setsid() really only seems to be there to have a controlling TTY if PID 1 is bash. Thanks, //richard
Am 22.06.2015 um 16:51 schrieb Daniel P. Berrange:
Also note systemd uses the device via /dev/console, not /dev/tty1 and with 'container_ttys' we've told it not to use /dev/tty1 for gettys. So maybe it deals with /dev/console in a different way than it would if it were /dev/tty1
BTW: Why are /dev/console and /dev/tty1 symlinks? IMHO we could make them bind mounts to /dev/pts/XY. That way one does not have to insert "pts/0" and such to /etc/securetty. Thanks, //richard
On Tue, Jun 23, 2015 at 02:20:54PM +0200, Richard Weinberger wrote:
Am 22.06.2015 um 16:51 schrieb Daniel P. Berrange:
Also note systemd uses the device via /dev/console, not /dev/tty1 and with 'container_ttys' we've told it not to use /dev/tty1 for gettys. So maybe it deals with /dev/console in a different way than it would if it were /dev/tty1
BTW: Why are /dev/console and /dev/tty1 symlinks? IMHO we could make them bind mounts to /dev/pts/XY.
That way one does not have to insert "pts/0" and such to /etc/securetty.
Again, just the way they happen to have been implemented historically. If the bind mount works better we could certainly do that. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
Daniel P. Berrange -
Richard Weinberger