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?

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.

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.