[systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

["Jóhann B. Guðmundsson"]

On 02/12/2015 04:38 AM, Michael Biebl wrote:
> 2015-02-11 20:12 GMT+01:00 Lennart Poettering <lennart at 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