+++ This bug was initially created as a clone of Bug #624249 +++ Sergei LITVINENKO: > Also, I found strange: > > [root@rawhide ~]# runlevel > N 4 Lennart Poettering: > By default runlevels 2, 3, 4 are just aliases for the same target > "multi-user.target". If you query the current runlevel, then systemd will > return you the highest runlevel that makes sense. That has the effect that even > though requested 3 you got 4, which is effectively the same. This will cause trouble with scripts which assume Red Hat's long practice of using runlevel 3 for text-only multiuser mode. They might be making a poor assumption, but those scripts are surely out there. Let's not break them. Since runlevel 4 is, in that same tradition, unused or left as user-defined, I think the easy fix is to just make runlevel 4 not be an alias for multi-user.target.
Well, but responding 3 or 4 is equally true in the default install.
> Well, but responding 3 or 4 is equally true in the default install. You mean insomuch as they are identical because you've done away with them. I get that, but is there any reason to make 4 be identical? The /etc/inittab in Red Hat Linux, RHEL, and Fedora has long documented them like this (even under upstart): # Default runlevel. The runlevels used are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) So, let's just keep 4 as unused, and then when you're in runlevel 3, the runlevel command will tell you "3". Am I missing something?
Despite what the comment says, in existing RHL/RHEL/Fedora installs, if you run 'telinit 4', you'll get the same thing as 'telinit 3'. (more or less... there could be some random service that decides to disable itself in runlevel 4, but that would be the rare exception.)
To be more clear - I think we should fix this somehow, I just don't think removing the alias is the correct fix.
(In reply to comment #3) > Despite what the comment says, in existing RHL/RHEL/Fedora installs, if you run > 'telinit 4', you'll get the same thing as 'telinit 3'. (more or less... there > could be some random service that decides to disable itself in runlevel 4, but > that would be the rare exception.) Historically, there were a bunch of packages with "# chkconfig: 235 nn nn" in their initscripts. But that seems to be no longer the case. Maybe no longer the case for a long time. (I see that vmware-tools apparently still does, but I think officially we can not care about that.) But sure, I don't actually care *how* it's fixed. How about 'multi-user-local.target', which by default just does everything 'multi-user.target' does?
So, what I changed now in systemd git is that if multiple possible answers to the question "which runlevel are we in?" make sense we will prefer the answers "5" and "3" (in this order) and only if neither applies consider the other numbers. Since 5 and 3 are what anaconda writes and is widely understood this should mostly fix the problems with people doing "if [ `runlevel` == 5 ] ; then" checks.
Cool, thanks.