5

As far as I know when we boot Linux system the services mentioned in runlevels (rcX.d) would be started.

If we enable any service to start during boot-up using systemctl command then will that service will be added to that default runlevel?

6

Actually no, it does not but you can run:

systemctl show -p WantedBy service-name

to find that in which target it would be run, for example:

systemctl show -p WantedBy tlp.service 
WantedBy=multi-user.target

which indicates that if I enable tlp it would be started when I get into multi-user.target.

Also worth to mention that run-levels are deprecated and systemd uses target instead:

┌─────────┬───────────────────┐
│Runlevel │ Target            │
├─────────┼───────────────────┤
│0        │ poweroff.target   │
├─────────┼───────────────────┤
│1        │ rescue.target     │
├─────────┼───────────────────┤
│2, 3, 4  │ multi-user.target │
├─────────┼───────────────────┤
│5        │ graphical.target  │
├─────────┼───────────────────┤
│6        │ reboot.target     │
└─────────┴───────────────────┘
2
  • 1
    Thanks for the answer. First of all I wanna say sorry that I didn't get exactly as I'm new to Linux. My doubts are: 1. where are target files stored in ubuntu? 2. why is run level needed when there's a concept of targets? 3. when we enable any service will that service will be added in rcx.d files also? 4. when system boots from where it will fetch the list of services to start? Thank you. – Shrey Kanna Sep 7 '18 at 6:27
  • @ShreyKanna Runlevels are an outdated concept from the days when sysv-init was used to boot up the system. Systemd introduced the concept of targets and maintains a mapping of the old runlevels for compatibillity. In cases where there's only a legacy service definition available, it will automatically try to create a unit file from it, and link it to the appropriate target.wants directory. Systemd never uses the rcx.d directories. – Bachsau Jul 15 '20 at 12:27
3

As far as I know when we boot Linux system the services mentioned in runlevels (rcX.d) would be started.

This is not true anymore.

The systemd init system does not natively use a concept of run-levels. Instead, it introduces a concept of "targets" which group other units by using the mechanism of dependencies.

What was a "default runlevel" becomes the default.target unit which, when activated (started), can "pull in" (activate) other units via requirement dependencies.

(systemd does provide some compatibility layer for the run-level concept, in form of giving some targets aliases with names like runlevelX.target, which are then used by the tools like telinit, but that's about it. In systemd, a service or any other unit is not required to belong to any of these pseudo-runlevels.)

To enable a service (usually) is to create an artificial dependency between two units.

So, when you enable a service (or any unit), systemd takes a look at that unit's [Install] section and performs actions specified therein. For example, let's take a look at sshd.service on my machine:

# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH Daemon
Wants=sshdgenkeys.service
After=sshdgenkeys.service
After=network.target

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

# This service file runs an SSH daemon that forks for each incoming connection.
# If you prefer to spawn on-demand daemons, use sshd.socket and sshd@.service.

When you write systemctl enable sshd.service, systemd looks at this unit and adds a Wants= dependency from multi-user.target to sshd.service according to the WantedBy=multi-user.target directive.

(This dependency is physically stored as a symlink from /etc/systemd/system/multi-user.target.wants to /usr/lib/systemd/system/sshd.service.)

So, when you boot...

When you boot, default.target gets activated, along with anything else it pulls in via dependencies. This is called "the initial transaction", and that's it.

Your default.target is likely an alias to graphical.target (which Wants=multi-user.target) or to multi-user.target directly. Either way, multi-user.target gets activated and pulls in sshd.service via the above-mentioned dependency.

3
  • thanks for the answer. I have some doubts please clarify it.1. where are target files stored in ubuntu? 2. why is run level needed when there's a concept of targets? 3. when we enable any service will that service will be added in rcx.d files also? 4. when system boots from where it will fetch the list of services to start? Thank you. – Shrey Kanna Sep 7 '18 at 6:49
  • @ShreyKanna 1. Alongside other units, see man systemd. 2. It's not. 3. Not necessarily, because enablement is not restricted to WantedBy= from runlevel-mapped targets. 4. When system boots, it starts default.target. Everything else is started by dependency. – intelfx Sep 7 '18 at 17:11
  • gr8 Q&A, @intelfx, on my system I see sshd.service linked to file in system dirlrwxrwxrwx 1 root root 31 Jul 22 22:42 /etc/systemd/system/sshd.service -> /lib/systemd/system/ssh.service . what does files in system folder mean, by which target will be used – samshers Aug 26 '19 at 5:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.