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?
Stack Exchange network consists of 181 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.Visit Stack Exchange
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.Sign up to join this community
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
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 │ └─────────┴───────────────────┘
As far as I know when we boot Linux system the services mentioned in runlevels (rcX.d) would be started.
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.)
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
sshd.service according to the
(This dependency is physically stored as a symlink from
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.
default.target is likely an alias to
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.
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.
lrwxrwxrwx 1 root root 31 Jul 22 22:42 /etc/systemd/system/sshd.service -> /lib/systemd/system/ssh.service. what does files in
systemfolder mean, by which target will be used