Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 626498 - runlevel 3 reported as runlevel 4
runlevel 3 reported as runlevel 4
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-23 13:04 EDT by Matthew Miller
Modified: 2010-08-24 21:50 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 624249
Environment:
Last Closed: 2010-08-24 21:33:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2010-08-23 13:04:40 EDT
+++ 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.
Comment 1 Lennart Poettering 2010-08-23 13:26:46 EDT
Well, but responding 3 or 4 is equally true in the default install.
Comment 2 Matthew Miller 2010-08-23 13:37:09 EDT
> 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?
Comment 3 Bill Nottingham 2010-08-23 13:51:59 EDT
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.)
Comment 4 Bill Nottingham 2010-08-23 13:54:56 EDT
To be more clear - I think we should fix this somehow, I just don't think removing the alias is the correct fix.
Comment 5 Matthew Miller 2010-08-23 14:12:43 EDT
(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?
Comment 6 Lennart Poettering 2010-08-24 21:33:07 EDT
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.
Comment 7 Matthew Miller 2010-08-24 21:50:21 EDT
Cool, thanks.

Note You need to log in before you can comment on or make changes to this bug.