Felipe Sateler <fsateler@debian.org> writes:
...
> This is indeed unfortunate. Because runlevel[234] are links to
> multi-user.target it means that distinctions between those runlevels are
> not preserved. It also means that the ability to differentiate between
> graphical.target and multi-user.target is almost lost for systems where the
> dm does not provide a native systemd unit, because the sysv generator will
> generate links from runlevel[2345].target.wants/ to the dm.
>
> This is the case with kdm:
>
> % cd /run/systemd/generator.late
> % ls -l runlevel[2345].target.wants/kdm.service
> lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel2.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service
> lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel3.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service
> lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel4.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service
> lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel5.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service
>
>
> Unless a user has disabled kdm in runlevels [234], there is no way to boot
> the system without starting kdm.
Is this not really a consequence of the combination of the fact that:
Firstly, Debian Policy has left runlevels mostly alone, with the intent that
local admins can do what they like with 3 & 4, and probably 5, because
we default to 2 where we run everything that's installed, including
graphical stuff; and secondly systemd seems to be using the more
conventional assumption that runlevel 5 is the graphical one, and lower
numbers run the non-graphical stuff only.
It seems to me that we could:
Make systemd link runlevel 2 to graphical.target, and 3,4 & 5 to
multi-user.target, or perhaps in an attempt to be slightly less
confusing to outsiders, how about:
2 & 5 --> graphical
3 & 4 --> multi-user
Ensure that all graphical stuff (so display managers basically) get
rid of their 234 runlevel start links, and change our default to 5
(cannot see that going well on upgrades TBH, might have been doable if
we'd started about 5 years ago)
Ensure that all display managers ship native systemd units before
release.
The last of these seems likely to at least partially address the problem
at hand, because it'll make it possible to use the multi-user.target to
avoid starting X, but does not fix the potential runlevel confusion.
Given that we do not have well defined distinctions between runlevels,
and the runlevels in systemd don't actually map directly to the old
runlevels anyway, but rather go via the multi-user and graphical
targets, should we not just remove the runlevel targets to avoid
this confusion (or do they get used elsewhere)?
I'd think that we need to tell people when upgrading that, if they've
done things that are important to them involving special meanings for
runlevels 2345, they need to work out how to port those things to
systemd, or opt to stick with sysvinit for now.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
pgpyOIzQQxpJJ.pgp
Description: PGP signature