4

When I run a basic Docker container (from within Google Cloud Shell) like so

docker pull debian
docker run -i -t debian:wheezy /bin/bash

and then type runlevel at the running container's shell prompt, the run level is unknown. Am I supposed to install (apt-get) particular packages in order to add support for run levels. If so, which ones, or what else could be wrong?

Drux
  • 11,992
  • 13
  • 66
  • 116

2 Answers2

5

Docker is an application isolation tool, not an OS virtualization tool. Runlevels are at the OS level, the OS comes up, mounts directories, and starts services to achieve a runlevel. In a container, your application is launched, the end. You can assume the container is at a single user run level, since you're the only user accessing the environment, but it really shouldn't matter for installing applications.

BMitch
  • 231,797
  • 42
  • 475
  • 450
  • I see, looks as if I made the same rookie mistake as also of issue [here](http://stackoverflow.com/questions/27154567/ubuntu-12-04-into-docker-service-mysql-start). Can you perhaps point to an article that explains further about the difference between the application isolation tool and an OS virtualization tool, so I can learn in a systematic way what else may be different inside a container opposite an VM image? – Drux Jul 18 '16 at 01:16
  • 2
    The question on the [differences between Docker and VMs](http://stackoverflow.com/q/16047306/596285) is old but may still be helpful. – BMitch Jul 18 '16 at 02:31
4

BMitch is right. Docker has nothing to do with runlevels, it will never change a runlevel. But there is more.

runlevel unknown is common on some systems running systemd. Your question is tagged with Debian though, and Debian Jessie (the latest Debian release, which uses systemd, uses compatibility script to print a runlevel). Arch based distros, and the unstable RedHat based distros (e.g. Fedora) print unknown when executing runlevel, i.e. they do not even care to print a fake runlevel.

If you check your runlevel script you will get the following output on a recent distro:

$ ls -l $(which runlevel)
lrwxrwxrwx 1 root root 9 Jun 18 14:44 /usr/bin/runlevel -> systemctl

(that is on arch, runlevel is in /usr/sbin on Debian, but it also points to systemctl on Debian)

The runlevel script points to sysemtd control on most recent distros.

In general runlevel has no meaning on recent distros (because of systemd to which pretty much everyone switched to). If you look inside the /etc/rc.d/rc*.d/ directories, they're almost empty.

What is actually defining how init processes the system boot is the systemd default target, located here:

/lib/systemd/system/default.target

Or /etc/systemd/system/default.target, if that exists.

grochmal
  • 2,901
  • 2
  • 22
  • 28