[libvirt] lxc: setsid() usage
Richard Weinberger
richard at nod.at
Tue Jun 23 12:18:30 UTC 2015
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
More information about the libvir-list
mailing list