Bug#824779: container getty-static.service causes lxcfs high cpu usage

Michael Biebl biebl at debian.org
Sun Jul 17 23:30:34 BST 2016


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
- getty at .service 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20160718/5d85d1a4/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list