systemd has replaced SysVinit as the default service manager in Oracle Linux 7 (RHEL 7), but for the backward compatibility reason, the runlevel command is still available and it is a symbolic link to systemctl. Some old programs relies on the return result of runlevel to continue such as Oracle 12c installation prerequisite checks.

I needed to do a upgrade test — upgrading Oracle 12c to Oracle 19c on Oracle Linux 7. But when installing Oracle 12c, it failed with the prerequisite check for runlevel.

If I run the symbolic link “runlevel“, it just returned “unknown” to me although systemctl indicated the system was running at multi-user.target level which was SysVinit run level 3.

root@eiol7db02:/mnt# runlevel
 unknown

root@eiol7db02:/mnt# systemctl get-default
 multi-user.target

root@eiol7db02:/mnt# ls -lrt /usr/lib/systemd/system/runl*.target
 lrwxrwxrwx. 1 root root 15 Aug 31 13:30 /usr/lib/systemd/system/runlevel0.target -> poweroff.target
 lrwxrwxrwx. 1 root root 13 Aug 31 13:30 /usr/lib/systemd/system/runlevel1.target -> rescue.target
 lrwxrwxrwx. 1 root root 17 Aug 31 13:30 /usr/lib/systemd/system/runlevel2.target -> multi-user.target
 lrwxrwxrwx. 1 root root 17 Aug 31 13:30 /usr/lib/systemd/system/runlevel3.target -> multi-user.target
 lrwxrwxrwx. 1 root root 17 Aug 31 13:30 /usr/lib/systemd/system/runlevel4.target -> multi-user.target
 lrwxrwxrwx. 1 root root 16 Aug 31 13:30 /usr/lib/systemd/system/runlevel5.target -> graphical.target
 lrwxrwxrwx. 1 root root 13 Aug 31 13:30 /usr/lib/systemd/system/runlevel6.target -> reboot.target

It’s interesting to see that although “runlevel” is just a symbolic link to “systemctl“, it is handled differently when run them without any arguments. “runlevel” returned “unknown”, but “systemctl” gave me a whole bunch of output. And when giving “get-default” as the argument, they return differently:

root@eiol7db02:/mnt# which runlevel
 /usr/sbin/runlevel
 root@eiol7db02:/mnt# ls -lrt /usr/sbin/runlevel
 lrwxrwxrwx. 1 root root 16 Aug 31 13:30 /usr/sbin/runlevel -> ../bin/systemctl

root@eiol7db02:/mnt# runlevel get-default
 Too many arguments.
 root@eiol7db02:/mnt# systemctl get-default
 multi-user.target

Anyway, it looks like “runlevel” is obsolete on Oracle Linux 7, it should return something like “N 3” when running at level 3. I needed to figure out why it returned “unknown” to continue my installation of Oracle 12c. Fortunately “systemctl status” gave me a hint — it looked like there were 5 jobs queued somehow.

root@eiol7db02:~# systemctl status
 ● eiol7db02
     State: starting
      Jobs: 5 queued
    Failed: 1 units
     Since: Wed 2020-10-28 16:27:21 CDT; 2min 52s ago

When I checked the jobs, there was one called “loginscreen.service” running and it seemed other 4 were waiting on it.

root@eiol7db02:~# systemctl list-jobs
 JOB UNIT                                 TYPE  STATE
 267 systemd-readahead-done.timer         start waiting
 218 systemd-update-utmp-runlevel.service start waiting
 102 multi-user.target                    start waiting
 276 loginscreen.service                  start running
 643 getty@tty6.service                   start waiting
 5 jobs listed.

Then I went back to the console and I saw there was a message saying “Press enter to continue”. After I hit enter, and jobs were gone. “runlevel” worked!

root@eiol7db02:~# systemctl list-jobs
 No jobs running.
 root@eiol7db02:~# runlevel
 N 3

root@eiol7db02:~# systemctl status
 ● eiol7db02
     State: degraded
      Jobs: 0 queued
    Failed: 1 units
     Since: Wed 2020-10-28 16:27:21 CDT; 9min ago

So this Linux 7 system has a login service script to show some information on the console and it uses a “read -p” to wait for someone to hit “enter” after reviewing the information. Until then the job is in waiting state which blocks the system to enter run level 3 (multi-user.target).

• Linux