Bug#772700: vt2-6 still not available with base system

[Michael Biebl]

[dropping debian-boot from CC]

Hi Simon,

Am 12.12.2014 um 17:18 schrieb Simon McVittie:
> On 12/12/14 15:26, Michael Biebl wrote:
>> Since apparently Conditions can't be used on targets, I came up with a
>> slightly different idea, using a service, which triggers the start of
>> getty on tty2-6 in absence of /usr/bin/dbus-daemon.
> 
> Any reason not to prefer "Wants=getty at tty2.service ...
> getty at tty6.service" and "ExecStart=/bin/true"?

Ansgar asked the same question on #debian-systemd.

The issue apparently is, that Conditions are evaluated way too late and
have no influence on the dependency graph. So getty at tty[2-6].service
would already be scheduled to be started, no matter if the Condition in
static-getty.service evaluates to true or false.

>> The advantage of that static-getty.service compared to enabling getty on
>> tty2-6 is, that we can easily drop that again in jessie+X once we have
>> kdbus.
> 
> I understand that advantage over Samuel's proposal, but if I was the
> systemd maintainer, I'd be very tempted to drop the Condition and run
> all six gettys unconditionally, preserving traditional functionality.
> logind's ability to start gettys on-demand is nice, and saves a bit of
> memory (and critical-boot-path I/O), but it's hardly a killer feature:
> after all, sysvinit has always started all six gettys by default.
> 
> If sysadmins with dbus installed (or less need for gettys) do want to
> disable it and save a bit of memory, masking static-getty.service is
> easily done.

With the suggested static-getty.service, you'd always get the
traditional behaviour of having 6 gettys (with the only difference that
with dbus installed, they are started on demand).
It's unclear to me why you don't want to make use of that feature, if
available. Can you elaborate?

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/20141212/47987fcb/attachment-0005.sig>