[systemd-devel] Is %i supported in Condition?

[Michael Biebl]

2016-07-19 13:07 GMT+02:00 Lennart Poettering <mzerqung at 0pointer.de>:
> On Tue, 19.07.16 12:45, Michael Biebl (mbiebl at 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 at .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 at .service instead of getty at .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 at .service
> (instead of serial-getty at .service or container-getty at .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 at .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?