Bug#772700: vt2-6 still not available with base system
On 12/12/14 16:55, Michael Biebl wrote: Am 12.12.2014 um 17:18 schrieb Simon McVittie: Any reason not to prefer Wants=getty@tty2.service ... getty@tty6.service and ExecStart=/bin/true? The issue apparently is, that Conditions are evaluated way too late and have no influence on the dependency graph. Fair enough. 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? IMO it simplifies testing if we're using the same code path regardless of whether dbus is installed. Not a strong objection if you strongly prefer the on-demand setup. I'm still a bit wary about having dbus turn up in minimal chroots, but perhaps bumping it up to Priority: important wouldn't be so bad - that would put it in a normal or fakechroot debootstrap, but not minbase or buildd. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772700: vt2-6 still not available with base system
Am 08.12.2014 um 01:12 schrieb Samuel Thibault: Michael Biebl, le Thu 04 Dec 2014 00:10:57 +0100, a écrit : Am 03.12.2014 um 22:42 schrieb Samuel Thibault: Simon McVittie, le Sun 09 Nov 2014 20:43:36 +, a écrit : I'm very tempted to say systemd in Debian should just make these 5 symlinks to preserve traditional Debian behaviour, at least for jessie. It doesn't really even need to run systemctl, it can just use ln -s or whatever. People who are so desperately short of memory that 5 agetty instances are undesired can always disable them. If you want it to be clear that it's a Debian-specific thing that's pulling them in, maybe it would be better to add a new debian-gettys.target or debian-gettys.service that Wants them, and make it WantedBy an appropriate target? That looks like the simplest way for now. Does anyone want to look into this and provide a patch for such a static gettys target. Maybe we could even make it Conditional on /usr/bin/dbus-daemon not being installed. I don't know how to do that, here is a more trivial way: simply doing the same as for tty1. I can confirm that this also fixes bug #760916. 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. 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. Removing the symlinks in /etc/systemd/system/getty.target.wants/ on upgrades is tricky, since those can actually be created by the admin and in this case we don't want to remove it. Comments welcome Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? [Unit] Description=Start static gettys on tty2-tty6 ConditionFileIsExecutable=!/usr/bin/dbus-daemon [Service] Type=oneshot ExecStart=/bin/systemctl --no-block start getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service RemainAfterExit=true [Install] WantedBy=multi-user.target signature.asc Description: OpenPGP digital signature
Bug#772700: vt2-6 still not available with base system
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@tty2.service ... getty@tty6.service and ExecStart=/bin/true? 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. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772700: vt2-6 still not available with base system
Simon McVittie, le Fri 12 Dec 2014 16:18:13 +, a écrit : 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@tty2.service ... getty@tty6.service and ExecStart=/bin/true? 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. And fixing #760916 along the way. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772700: vt2-6 still not available with base system
[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@tty2.service ... getty@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@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? signature.asc Description: OpenPGP digital signature
