When we enable any service using systemctl, in which runlevel would that service run?

Question

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?

Answer 1

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     │
└─────────┴───────────────────┘

Answer 2

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.