На самом деле не это не делает, но можно работать:

systemctl show -p WantedBy service-name

чтобы найти что, в которой цели это было бы выполнено, например:

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

который указывает на это, если я включаю tlp это было бы запущено, когда я вхожу multi-user.target.

Также ценность, чтобы упомянуть, что уровни выполнения удерживаются от использования и цель использования systemd вместо этого:

┌─────────┬───────────────────┐
│Runlevel │ Target            │
├─────────┼───────────────────┤
│0        │ poweroff.target   │
├─────────┼───────────────────┤
│1        │ rescue.target     │
├─────────┼───────────────────┤
│2, 3, 4  │ multi-user.target │
├─────────┼───────────────────┤
│5        │ graphical.target  │
├─────────┼───────────────────┤
│6        │ reboot.target     │
└─────────┴───────────────────┘

Насколько я знаю, когда мы загружаем систему Linux, сервисы, упомянутые в runlevels (rcX.d), были бы запущены.

Это больше не верно.

systemd система init исходно не использует понятие уровней выполнения. Вместо этого это представляет понятие "целей", которые группируют другие единицы при помощи механизма зависимостей.

То, что было "значением по умолчанию runlevel", становится default.target единица, которая при активации (запустилась), может "сдержаться" (активируют) другие единицы через зависимости от требования.

(systemd действительно обеспечивает некоторый слой совместимости для понятия уровня выполнения, в форме предоставления некоторых целевых псевдонимов с именами как runlevelX.target, которые затем используются инструментами как telinit, но это об этом. В systemd, сервисе или любой другой единице не требуется, чтобы принадлежать любому из этих pseudo-runlevels.)

Включить сервис (обычно) означает создавать искусственную зависимость между двумя единицами.

Так, при включении сервиса (или любая единица) systemd смотрит на ту единицу [Install] разделите и выполняет действия, указанные там. Например, давайте смотреть на sshd.service на моей машине:

# /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.

Когда Вы пишете systemctl enable sshd.service, systemd смотрит на эту единицу и добавляет a Wants= зависимость от multi-user.target кому: sshd.service согласно WantedBy=multi-user.target директива.

(Эта зависимость физически хранится как символьная ссылка от /etc/systemd/system/multi-user.target.wants кому: /usr/lib/systemd/system/sshd.service.)

Так, когда Вы загружаетесь...

Когда Вы загружаетесь, default.target активируется, наряду с чем-либо еще, что это вытягивает на пути зависимости. Это называют "исходной транзакцией", и вот именно.

Ваш default.target вероятно псевдоним graphical.target (который Wants=multi-user.target) или к multi-user.target непосредственно. Так или иначе, multi-user.target активируется и сдерживается sshd.service через вышеупомянутую зависимость.