2016-07-19 13:07 GMT+02:00 Lennart Poettering <mzerq...@0pointer.de>: > On Tue, 19.07.16 12:45, Michael Biebl (mbi...@gmail.com) wrote: > >> > "tty0" is a nice way to detect whether the VC system is available. The >> > instances should be cleanly skipped if the VC system is not available >> > (because compiled out of the kernel, or because of a container >> > env). If the specific tty the service is started for is missing we >> > shouldn't eat up the error however, but rightly fail. >> >> Apparently this check is too simplistic though. LXC for example >> provides tty1-tty4 > > Nah, LXC is simply broken in this regard. They provide ptys they call > tty1-tty4 which are the names of the ttys provided by the VC > subsystem. However, their ptys are really not VCs, they do not speak > VC ioctls, they expect different $TERM settings, they do not come with > associated devices such as /dev/vcs0, /dev/vcs1, ... or /dev/vcsa0, > /dev/vcsa1, ... nor even /dev/tty0 itself, not with the relevant files > in /sys either (such as /sys/class/tty/tty0/active). You cannot load > fonts into them or unicode maps. You cannot run gpm on it and so > on. LXC really should not claim to support the VC subsystem if they > really really don't. > > They can pick any name they want for their ptys, but > /dev/tty1…/dev/tty4 are certainly the most inappropriate ones, and I > am very sure we shouldn't cater for that. Note that doing such > nonsense won't just break systemd's getty@.service logic, but also > logind, and more. > > Since a long long time systemd actually provides multiple alternatives > to what they want to achieve, without faking a really broken and > incomplete VC subsystem. Specifically, if they pass $container_ttys= > to PID 1 in the container systemd will automatically start correct > gettys on the specified ttys. gettys with the right TERM set, and > systemd won't bother with VC-specific ioctls on those ttys (such as > the stuff behind TTYVTDisallocate=). This will run > container-getty@.service instead of getty@.service on the relevant TTY > which differs in quite a number of options (for example l10n won't be > turned off anymore!). > > They could also stop doing static TTYs at all, and just dynamically > allocate a tty with a getty behind, the way "machinectl login" does > it. Or even run a shell directly, the way "machinectl shell" does > it... > > But of all of this, faking VC devices in such a borked way is really > the *worst* of all options. Running non-VC ttys with getty@.service > (instead of serial-getty@.service or container-getty@.service) is also > massively broken. > > BTW, this is all documented here: > > https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ > > I put that doc together so that container managers can set up the > environment for systemd nicely and things will just work, without > requiring hacks, or without having to modify systemd at all to work in > a container. Of course, if people don't read it then nobody is > helped... I even talked about this doc a few years ago at LPC, to make > this known... > >> And starting at getty on a non-existing tty1 simply makes it fail and >> systemd restarting it (due to Restart=always) >> That is not nice. >> >> > Hope that makes sense? >> >> Well, I think it would be better if we used >> ConditionPathExists=/dev/%i in getty@.service >> Makes a lot more sense to me, tbh. > > Nope, that's a hack. Please fix LXC to set up a non-broken environment > for systemd and everything will just work without faking any ttys...
I'm not an LXC developer, so I don't really have influence on that. Still, seems rather pointless to me to repeatedly start a getty on a tty that doesn't exist and hogging the CPU while doing so. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
