On 02/12/2015 04:38 AM, Michael Biebl wrote:
2015-02-11 20:12 GMT+01:00 Lennart Poettering <lenn...@poettering.net>:
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
Do you mean runlevel2-5, or is runlevel2 excluded for a reason?
Well we have more targets then there are run levels for example
emergency and rescue both of which could be seen as "run level 1"
Run level 2 arguably should have been mapped to basic.target from the
start and is causing confusion since it's mapped to the multi-user.target
Run level 3 as in the multi-user.target lacks network support ( even
thou now it arguably could be added properly with systemd-networkd ),
which is what users expect
Run level 4 cant be mapped to users custom boot target ( they have to
manually link it themselves and since they have to do that they are
simply better of using systemctl set-default <my-custom-boot.target>
reboot and then change it back or isolate to it.
etc.
The fact is if shit hits the fan at bootup systemd really aught to
handle that gracefully and drop users down to rescue.target and or
emergency.target and if you switch targets later then you should wind up
with only the exact services running as you would have booted directly
to the target you isolated to.
Forcing users having to add a kernel command line ( 1,2,3 etc ) is
archaic in the 21 century from my pov but unfortunately our huge timeout
that happens at bootup contributes to users having to manually boot to a
specific target ( or runlevel ) due to the fact users dont wait for that
time out ( by my observation these years if users are used boot
completing in <15s having them wait for more then ca 30s tops reaches
their patience threshold and they *will* in all cases hard power off the
machine and power it on again which beats the purpose of the time out to
begin with )
So arguably the entire concept of run levels ( and backward
compatibility and support ) should be put to rest upstream and have
downstream maintaining that compatibility support if they so much desire
since it never applied to systemd and doing so has and is hindering
adoption of the systemd concept of targets, causes confusion for users
and arguably hinders us evolve to a better native solution to solve the
usecases that inspired the existence of run levels to begin with.
JBG
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
