Am 18.07.2016 um 00:17 schrieb Michael Biebl: > Am 16.07.2016 um 15:34 schrieb Martin Pitt: >> Control: tag -1 pending >> >> Wang Jian [2016-05-19 23:59 +0800]: >>> getty-static.service starts getty on tty2-6, but container has only 4 >>> ttys (1-4) at default. getty will exit and be respawned for tty5-tty6. >>> This leads to high cpu usage on host's lxcfs daemon. >>> >> >> There is no point in even wasting four getty processes on tty1-4 in >> LXC -- containers are not meant to have gettys on ttys in the first >> place. I committed a fix to git for that. >> (ConditionVirtualization=!container) > > I just created a test jessie lxc container (using lxc 2.0.0-3~bpo8+1) on > jessie host system (using lxc-create -t download) > > The generated chroot had a /etc/systemd/system/getty-static.service > which was restricted to tty1-tty4 and was overriding the > getty-static.service shipped by the systemd package. > > I assume this file was created by lxc. > Apparently the lxc maintainers decided it is useful to have a getty on > tty1-tty4? lxc maintainers, could you give us some input here, why > getty-static.service was not completely disabled.
The generated lxc chroot has more interesting stuff: - systemd-udevd.service and udev.service are masked - sigpwr.target points to /lib/systemd/system/halt.target - [email protected] and getty-static.service are overriden. Could the lxc maintainers please chime in here, why that is done? Why wasn't the systemd team contacted so we can work on a solution which doesn't involve working behind someone's back? How are those lxc chroots created? Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
