Zum Inhalt springen

Systemd/Timers: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
Tuxnix (Diskussion | Beiträge)
Die Seite wurde neu angelegt: „{{inuse|~~~}} {{Lowercase title}} Category:Daemons and system services Category:Boot process de:Systemd/Timers fr:Systemd/cron ja:Systemd/タ…“
 
Tuxnix (Diskussion | Beiträge)
Gründlich Überarbeitung. Die Sektionen [Unit], [Install] und [Service] wurden herausgenommen und auf die man pages verwiesen. (Mehr waren dies Listen ohnehin nicht. Dafür liegt der Schwerpunkt nun auf der [Timer] Sektion.
 
(43 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{inuse|[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]])}}
{{righttoc}}
{{Lowercase title}}
Timer bieten die Möglichkeit Aufgaben zeitlich zu steuern. Die Timer-Unit besteht aus einer {{ic|.timer}} Datei die eine {{ic|.service}} Datei ansteuert. Timer unterstehen [[systemd]] und müssen mit dem systemctl Befehl aktiviert werden. Eine Alternative hierzu bietet [[cron]].
[[Category:Daemons and system services]]
[[Category:Boot process]]
[[de:Systemd/Timers]]
[[fr:Systemd/cron]]
[[ja:Systemd/タイマー]]
[[ru:Systemd/Timers]]
[[zh-hans:Systemd/Timers]]
{{Related articles start}}
{{Related|systemd}}
{{Related|systemd/User}}
{{Related|systemd FAQ}}
{{Related|cron}}
{{Related articles end}}
Timer bieten die Möglichkeit Aufgaben zeitgerecht zu steuern. Sie bestehen aus einer {{ic|.timer}} und einer {{ic|.service}} Datei.
Der Timer Dienst wird von [[systemd]] gesteuert und müssen mit einem systemctl Befehl aktiviert werden. Alternativen sind [[cron]] und [[anacron]].


==Hinweis==
== Beispiel ==
{{hc|1=beispiel.timer|2=
[Unit]
Description=Kurz-Beschreibung


Dies ist mein erster Archwicki Artikel. Er ist gerade erst im entstehen
[Timer]
Der englische Archwikiartikel dient lediglich als Vorlage.
OnBootSec=1h 30m


==Beispiel==
[Install]
WantedBy=basic.target}}


==={{ic|.timer}} Datei===
{{hc|1=beispiel.service|2=
[Unit]
Description=Kurz-Beschreibung


==={{ic|.service}} Datei===
[Service]
ExecStart=/usr/bin/beispiel.sh}}


===Aktivierung===
Service- und Timerdateien werden für
* systemweite Dienste im Ordner {{ic|/etc/systemd/system/}}
* userbezoge Dienste unter {{ic|~/.config/systemd/user/}} gespeichert.


== Timer units ==
Timer und Service müssen dabei den gleichen Namen tragen. Z.B.:
Timers are like other [[systemd#Writing unit files|unit configuration files]] and are loaded from the same paths but include a {{ic|[Timer]}} section.  The {{ic|[Timer]}} section defines when and how the timer activates. Timers are defined as one of two types:
({{ic|'''beispiel'''.timer}} und {{ic|'''beispiel'''.service}}).


* '''Monotonic timers''' activate after a time span relative to a varying starting point. There are number of different monotonic timers but all have the form of: {{ic|1=On''Type''Sec=}}{{ic|OnBootSec}} and {{ic|OnActiveSec}} are common monotonic timers.
== De- / Aktivierung ==
* '''Realtime timers''' (a.k.a. wallclock timers) activate on a calendar event (like cronjobs). The option {{ic|1=OnCalendar=}} is used to define them.
Mit {{ic|systemctl enable --now}} startet der Timer unverzüglich und permanent, sodass er auch nach einem Neustart aktiv ist. Ohne {{ic|--now}} werden {{ic|enable}} oder auch {{ic|disable}} erst nach einem reboot wirksam. Ein {{ic|start}} bzw. {{ic|stop}} wirken sich hingegen nur auf die laufende Sitzung aus. Bei der ersten Initialisierung legt das System automatisch einen passenden [[ln|Symlink]] an.


For a full explanation of timer options, see the {{man|5|systemd.timer}}. The argument syntax for calendar events and time spans is defined in {{man|7|systemd.time}}.
Timer für systemweite Dienste werden mit Rootrechten aktiviert:
# systemctl enable --now <name>.timer


== Service unit ==
Timer im Userbereich werden mit der Option {{ic|--user}} und mit Userrechten aktiviert:
$ systemctl --user enable --now <name>.timer


For each {{ic|.timer}} file, a matching {{ic|.service}} file exists (e.g. {{ic|foo.timer}} and {{ic|foo.service}}). The {{ic|.timer}} file activates and controls the {{ic|.service}} file. The {{ic|.service}} does not require an {{ic|[Install]}} section as it is the ''timer'' units that are enabled. If necessary, it is possible to control a differently-named unit using the {{ic|1=Unit=}} option in the timer's {{ic|[Timer]}} section.
Aktualisierung von Timer und Sevice nach einer Änderung:
  # systemctl reenable --now <name>.timer
  $ systemctl --user reenable --now <name>.timer


== Management ==
== Management ==
Auflistung der Auslösezeiten:
systemctl list-timers --all
(Sollen nur die aktiven Timer angezeigt werden genügt auch ein {{ic|systemctl list-timers}}).


To use a ''timer'' unit [[enable]] and [[start]] it like any other unit (remember to add the {{ic|.timer}} suffix). To view all started timers, run:
Statusmeldungen:
systemctl status <name>.timer
systemctl status <name>.service


{{hc|$ systemctl list-timers|
Journaleinträge z.B.:
NEXT                          LEFT        LAST                          PASSED    UNIT                        ACTIVATES
  journalctl -u <name>.service -g Started
Thu 2014-07-10 19:37:03 CEST  11h left    Wed 2014-07-09 19:37:03 CEST  12h ago    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2014-07-11 00:00:00 CEST 15h left    Thu 2014-07-10 00:00:13 CEST  8h ago    logrotate.timer              logrotate.service
}}


{{Note|
== Die [Timer] Sektion ==
* To list all timers (including inactive), use {{ic|systemctl list-timers --all}}.
( Für die Konfiguration der Sektionen [Unit], [Install] und [Service] sei an dieser Stelle auf die entsprechenden man pages verwiesen)
* The status of a service started by a timer will likely be inactive unless it is currently being triggered.
* If a timer gets out of sync, it may help to delete its {{ic|stamp-*}} file in {{ic|/var/lib/systemd/timers}}. These are zero length files which mark the last time each timer was run. If deleted, they will be reconstructed on the next start of their timer.}}


== Example ==
In der Timer Sektion können auch mehrere Zeitangaben gemacht werden. Sie beeinflussen sich nicht und werden alle zu ihrem jeweiligen Zeitpunkt ausgeführt.


No changes to service unit files are needed to schedule them with a timer. The following example schedules {{ic|foo.service}} to be run with a corresponding timer called {{ic|foo.timer}}.


=== Monotonic timer ===


A timer which will start 15 minutes after boot and again every week while the system is running.
=== Kalendarische Zeitangaben ===
* OnCalendar=


{{hc|/etc/systemd/system/foo.timer|<nowiki>
==== Absolute kalendarische Zeitangaben ====
[Unit]
Description=Run foo weekly and on boot


[Timer]
OnCalendar=Thu,Fri 2026-*-1..5 11:12:13
OnBootSec=15min
OnUnitActiveSec=1w


[Install]
(Der service wird jeweils um 11 Uhr 12, zwischen dem 1. und 5. Kalendertag eines jeden Monats des Jahres 2026 ausgelöst, wenn dies Donnerstage oder Freitage sind.)
WantedBy=timers.target
</nowiki>}}


=== Realtime timer ===
Die Angabe von Wochentagen erfolgt immer in Englisch und ist optional.
Jede Rubrik kann mit "," für die Aufzählung oder mit ".." für von bis versehen werden oder durch "*" für beliebig ersetzt werden.


A timer which starts once a week (at 12:00am on Monday). It starts once immediately if it missed the last start time (option {{ic|1=Persistent=true}}), for example due to the system being powered off:  
Die Angaben erfolgen nach diesem Schema:
OnCalendar=Wochentag(englisch/optional) Jahr-Monat-Tag Stunde:Minute:Sekunde


{{hc|/etc/systemd/system/foo.timer|<nowiki>
==== Periodische kalendarische Zeitangaben ====
[Unit]
Description=Run foo weekly


[Timer]
OnCalendar=weekly
OnCalendar=weekly
Persistent=true   
[Install]
WantedBy=timers.target</nowiki>}}


The format controlling {{ic|OnCalendar}} events uses the following format when more specific dates and times are required: {{ic|DayOfWeek Year-Month-Day Hour:Minute:Second}}. An asterisk may be used to specify any value and commas may be used to list possible values. Two values separated by {{ic|..}} may be used to indicate a contiguous range. In this example the service is run the first four days of each month at 12:00 PM, but ''only'' if that day is also on a Monday or a Tuesday. More information is available in {{man|7|systemd.time}}.
Auch diese Werte sind möglich.
minutely, hourly, daily, monthly, weekly, yearly, quarterly, semiannually


  OnCalendar=Mon,Tue *-*-01..04 12:00:00
Entsprechend den oberen Notierung, kann dafür auch diese Schreibweise genutzt werden.
  *-*-* *:*:00, *-*-* *:00:00, *-*-* 00:00:00, *-*-01 00:00:00, Mon *-*-* 00:00:00, *-01-01 00:00:00, *-01,04,07,10-01 00:00:00, *-01,07-01 00:00:00


{{Tip|Special event expressions like {{ic|daily}} and {{ic|weekly}} refer to ''specific start times'' and thus any timers sharing such calendar events will start simultaneously. Timers sharing start events can cause poor system performance if the timers' services compete for system resources. The {{ic|RandomizedDelaySec}} option avoids this problem by randomly staggering the start time of each timer. See {{man|5|systemd.timer}}.}}
==== Testen von OnCalendar= Zeitangaben ====
Kalendarische Zeitangaben können auf der Konsole mit folgendem Befehl auf Funktion geprüft werden:
  systemd-analyze calendar "<Zeitangabe>"


== Transient .timer units ==
Mit der Option {{ic|--iterations <N>}} werden weitere Auslösezeitpunkte aufgelistet.


One can use {{ic|systemd-run}} to create transient {{ic|.timer}} units. That is, one can set a command to run at a specified time without having a service file. For example the following command touches a file after 30 seconds:
=== Relative Zeitangaben ===
(Stehen in Relation zu anderen Ereignissen)


  # systemd-run --on-active=30 /bin/touch /tmp/foo
Beispiel:
  OnBootSec=2d 1h 30m


One can also specify a pre-existing service file that does not have a timer file. For example, the following starts the systemd unit named {{ic|''someunit''.service}} after 12.5 hours have elapsed:
====Einmalige Ereignisse====
* OnBootSec=  - Die Zeitspanne seit dem Booten des Rechners.
* OnStartupSec= - Die Zeitspanne seit dem Start von systemd.
* OnActiveSec= - Die Zeitspanne seit Aktivierung der Timer-Unit.


  # systemd-run --on-active="12h 30m" --unit ''someunit''.service
====Wiederkehrende Ereignisse====
* OnUnitActiveSec= - Die Zeitspanne seit dem der Timer das letzte mal den Job ausgelöst hat.
* OnUnitInactiveSec= - Die Zeitspanne seit der Beendigung des letzten Jobs.


See {{man|1|systemd-run}} for more information and examples.
Folgende Einheiten können für relative Zeitangaben gewählt werden:
usec, us
msec, ms
seconds, second, sec, s
minutes, minute, min, m
hours, hour, hr, h
days, day, d
weeks, week, w
months, month, M (definiert als 30.44 Tage)
years, year, y (definiert als 365.25 Tage)
(Ohne Verwendung einer Einheit werden alle Angaben als Sekunden gewertet.)


== As a cron replacement ==
==== Testen Relativer Zeitangaben ====
Relative Zeitangaben können auf der Konsole mit folgendem Befehl auf Funktion geprüft werden:
systemd-analyze timespan "<Zeitangabe>"


Although [[cron]] is arguably the most well-known job scheduler, ''systemd'' timers can be an alternative.
=== Weitere Optionen in [Timer] ===
* AccuracySec= -  Bestimmt die Genauigkeit des Auslösezeitpunkts (default 1 min).
* RandomizedDelaySec= - Wird verwendet damit nicht mehrere Timer exakt gleichzeitig z.B um 00:00 loslegen.
* WakeSystem= - Weckt das System aus dem suspend mode.
* Unit= - Als default ist dieser Wert identisch mit dem Suffix der .timer Datei (s. oben). Bei Verwendung  muss eine Datei mit dem hier angegebenen Namen existieren. Eine Verschachtelung von Units ist möglich.
* Persistent=true - Bewirkt, dass ein versäumter Job beim nächsten Rechnerstart unverzüglich nachgeholt wird.
* RemainAfterElapse=false - beendet den Timer nach einmaliger Ausführung.


=== Benefits ===
== Manpages ==


The main benefits of using timers come from each job having its own ''systemd'' service. Some of these benefits are:
systemctl, systemd, systemd-analyze, systemd.directives, systemd.service, systemd.socket, systemd.special, systemd-system.conf, systemd.time, systemd.timer, systemd.unit


* Jobs can be easily started independently of their timers. This simplifies debugging.
== Siehe auch ==
* Each job can be configured to run in a specific environment (see {{man|5|systemd.exec}}).
* [[systemd]]
* Jobs can be attached to [[cgroups]].
* [[systemd/Eigener Service|Einen eigenen systemd-Service erstellen]]
* Jobs can be set up to depend on other ''systemd'' units.
* [[Automatische Sicherung (Beispiel)]]
* Jobs are logged in the ''systemd'' journal for easy debugging.


=== Caveats ===
== Weblinks ==
* [https://documentation.suse.com/de-de/sle-micro/6.0/pdf/Micro-systemd-working-with-timers_de.pdf suse - Arbeiten mit systemd-Zeitgebern ] {{sprache|de}}
* [https://kofler.info/systemd-timer-als-cron-alternative/ Michael Kofler Blog] Anleitung und Beispiel {{sprache|de}}
* [https://wiki.gentoo.org/wiki/Systemd#Timer_services Gentoo wiki section] on ''systemd'' timer services {{sprache|en}}


Some things that are easy to do with cron are difficult to do with timer units alone.
[[Kategorie:Systemverwaltung]]
[[Kategorie:Service]]


* Complexity: to set up a timed job with ''systemd'' you create two files and run a couple {{ic|systemctl}} commands. Compare that to adding a single line to a crontab.
[[en:Systemd/Timers]]
* Emails: there is no built-in equivalent to cron's {{ic|MAILTO}} for sending emails on job failure. See the next section for an example of setting up a similar setup using {{ic|1=OnFailure=}}.
[[fr:Systemd/cron]]
 
[[ja:Systemd/タイマー]]
=== MAILTO ===
[[ru:Systemd/Timers]]
 
You can set up systemd to send an e-mail when a unit fails. Cron sends mail to {{ic|MAILTO}} the job outputs to stdout or stderr, but many jobs are setup to only output on error. First you need two files: an executable for sending the mail and a ''.service'' for starting the executable. For this example, the executable is just a shell script using {{ic|sendmail}}:
 
{{hc|/usr/local/bin/systemd-email|<nowiki>#!/bin/bash
 
/usr/bin/sendmail -t <<ERRMAIL
To: $1
From: systemd <root@$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
 
$(systemctl status --full "$2")
ERRMAIL</nowiki>}}
 
Whatever executable you use, it should probably take at least two arguments as this shell script does: the address to send to and the unit file to get the status of. The ''.service'' we create will pass these arguments:
 
{{hc|/etc/systemd/system/status-email-''user''@.service|2=[Unit]
Description=status email for %i to ''user''
 
[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email ''address'' %i
User=nobody
Group=systemd-journal}}
 
Where {{ic|''user''}} is the user being emailed and {{ic|''address''}} is that user's email address. Although the recipient is hard-coded, the unit file to report on is passed as an instance parameter, so this one service can send email for many other units. At this point you can [[start]] {{ic|status-email-''user''@dbus.service}} to verify that you can receive the emails.
 
Then simply [[systemd#Editing provided units|edit]] the service you want emails for and add {{ic|1=OnFailure=status-email-''user''@%n.service}} to the {{ic|[Unit]}} section. {{ic|%n}} passes the unit's name to the template.
 
{{note|
* If you set up SSMTP security according to [[SSMTP#Security]] the user {{ic|nobody}} will not have access to {{ic|/etc/ssmtp/ssmtp.conf}}, and the {{ic|systemctl start status-email-''user''@dbus.service}} command will fail. One solution is to use {{ic|root}} as the User in the {{ic|status-email-''user''@.service}} unit.
* If you try to use {{ic|mail -s somelogs ''address''}} in your email script, {{ic|mail}} will fork and systemd will kill the mail process when it sees your script exit. Make the mail non-forking by doing {{ic|mail -Ssendwait -s somelogs ''address''}}.}}
 
=== Using a crontab ===
 
Several of the caveats can be worked around by installing a package that parses a traditional crontab to configure the timers. {{AUR|systemd-cron-next}} and {{AUR|systemd-cron}} are two such packages. These can provide the missing {{ic|MAILTO}} feature.
 
If you like crontabs just because they provide a unified view of all scheduled jobs, {{ic|systemctl}} can provide this. See [[#Management]].
 
== See also ==
 
* {{man|5|systemd.timer}}
* [https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Fedora Project wiki page] on ''systemd'' calendar timers
* [https://wiki.gentoo.org/wiki/Systemd#Timer_services Gentoo wiki section] on ''systemd'' timer services
* {{App|systemd-cron-next|tool to generate timers/services from crontab and anacrontab files|https://github.com/systemd-cron/systemd-cron-next|{{Aur|systemd-cron-next}}}}
* {{App|systemd-cron|provides systemd units to run cron scripts; using ''systemd-crontab-generator'' to convert crontabs|https://github.com/systemd-cron/systemd-cron|{{Aur|systemd-cron}}}}

Aktuelle Version vom 28. September 2025, 11:48 Uhr

Timer bieten die Möglichkeit Aufgaben zeitlich zu steuern. Die Timer-Unit besteht aus einer .timer Datei die eine .service Datei ansteuert. Timer unterstehen systemd und müssen mit dem systemctl Befehl aktiviert werden. Eine Alternative hierzu bietet cron.

Beispiel

beispiel.timer
[Unit]
Description=Kurz-Beschreibung

[Timer]
OnBootSec=1h 30m

[Install]
WantedBy=basic.target
beispiel.service
[Unit]
Description=Kurz-Beschreibung

[Service]
ExecStart=/usr/bin/beispiel.sh

Service- und Timerdateien werden für

  • systemweite Dienste im Ordner /etc/systemd/system/
  • userbezoge Dienste unter ~/.config/systemd/user/ gespeichert.

Timer und Service müssen dabei den gleichen Namen tragen. Z.B.: (beispiel.timer und beispiel.service).

De- / Aktivierung

Mit systemctl enable --now startet der Timer unverzüglich und permanent, sodass er auch nach einem Neustart aktiv ist. Ohne --now werden enable oder auch disable erst nach einem reboot wirksam. Ein start bzw. stop wirken sich hingegen nur auf die laufende Sitzung aus. Bei der ersten Initialisierung legt das System automatisch einen passenden Symlink an.

Timer für systemweite Dienste werden mit Rootrechten aktiviert:

# systemctl enable --now <name>.timer

Timer im Userbereich werden mit der Option --user und mit Userrechten aktiviert:

$ systemctl --user enable --now <name>.timer

Aktualisierung von Timer und Sevice nach einer Änderung:

# systemctl reenable --now <name>.timer
$ systemctl --user reenable --now <name>.timer

Management

Auflistung der Auslösezeiten:

systemctl list-timers --all

(Sollen nur die aktiven Timer angezeigt werden genügt auch ein systemctl list-timers).

Statusmeldungen:

systemctl status <name>.timer
systemctl status <name>.service

Journaleinträge z.B.:

journalctl -u <name>.service -g Started

Die [Timer] Sektion

( Für die Konfiguration der Sektionen [Unit], [Install] und [Service] sei an dieser Stelle auf die entsprechenden man pages verwiesen)

In der Timer Sektion können auch mehrere Zeitangaben gemacht werden. Sie beeinflussen sich nicht und werden alle zu ihrem jeweiligen Zeitpunkt ausgeführt.


Kalendarische Zeitangaben

  • OnCalendar=

Absolute kalendarische Zeitangaben

OnCalendar=Thu,Fri 2026-*-1..5 11:12:13

(Der service wird jeweils um 11 Uhr 12, zwischen dem 1. und 5. Kalendertag eines jeden Monats des Jahres 2026 ausgelöst, wenn dies Donnerstage oder Freitage sind.)

Die Angabe von Wochentagen erfolgt immer in Englisch und ist optional. Jede Rubrik kann mit "," für die Aufzählung oder mit ".." für von bis versehen werden oder durch "*" für beliebig ersetzt werden.

Die Angaben erfolgen nach diesem Schema:

OnCalendar=Wochentag(englisch/optional) Jahr-Monat-Tag Stunde:Minute:Sekunde

Periodische kalendarische Zeitangaben

OnCalendar=weekly

Auch diese Werte sind möglich.

minutely, hourly, daily, monthly, weekly, yearly, quarterly, semiannually

Entsprechend den oberen Notierung, kann dafür auch diese Schreibweise genutzt werden.

*-*-* *:*:00, *-*-* *:00:00, *-*-* 00:00:00, *-*-01 00:00:00, Mon *-*-* 00:00:00, *-01-01 00:00:00, *-01,04,07,10-01 00:00:00, *-01,07-01 00:00:00

Testen von OnCalendar= Zeitangaben

Kalendarische Zeitangaben können auf der Konsole mit folgendem Befehl auf Funktion geprüft werden:

systemd-analyze calendar "<Zeitangabe>"

Mit der Option --iterations <N> werden weitere Auslösezeitpunkte aufgelistet.

Relative Zeitangaben

(Stehen in Relation zu anderen Ereignissen)

Beispiel:

OnBootSec=2d 1h 30m

Einmalige Ereignisse

  • OnBootSec= - Die Zeitspanne seit dem Booten des Rechners.
  • OnStartupSec= - Die Zeitspanne seit dem Start von systemd.
  • OnActiveSec= - Die Zeitspanne seit Aktivierung der Timer-Unit.

Wiederkehrende Ereignisse

  • OnUnitActiveSec= - Die Zeitspanne seit dem der Timer das letzte mal den Job ausgelöst hat.
  • OnUnitInactiveSec= - Die Zeitspanne seit der Beendigung des letzten Jobs.

Folgende Einheiten können für relative Zeitangaben gewählt werden:

usec, us
msec, ms
seconds, second, sec, s
minutes, minute, min, m
hours, hour, hr, h
days, day, d
weeks, week, w
months, month, M (definiert als 30.44 Tage)
years, year, y (definiert als 365.25 Tage)

(Ohne Verwendung einer Einheit werden alle Angaben als Sekunden gewertet.)

Testen Relativer Zeitangaben

Relative Zeitangaben können auf der Konsole mit folgendem Befehl auf Funktion geprüft werden:

systemd-analyze timespan "<Zeitangabe>"

Weitere Optionen in [Timer]

  • AccuracySec= - Bestimmt die Genauigkeit des Auslösezeitpunkts (default 1 min).
  • RandomizedDelaySec= - Wird verwendet damit nicht mehrere Timer exakt gleichzeitig z.B um 00:00 loslegen.
  • WakeSystem= - Weckt das System aus dem suspend mode.
  • Unit= - Als default ist dieser Wert identisch mit dem Suffix der .timer Datei (s. oben). Bei Verwendung muss eine Datei mit dem hier angegebenen Namen existieren. Eine Verschachtelung von Units ist möglich.
  • Persistent=true - Bewirkt, dass ein versäumter Job beim nächsten Rechnerstart unverzüglich nachgeholt wird.
  • RemainAfterElapse=false - beendet den Timer nach einmaliger Ausführung.

Manpages

systemctl, systemd, systemd-analyze, systemd.directives, systemd.service, systemd.socket, systemd.special, systemd-system.conf, systemd.time, systemd.timer, systemd.unit

Siehe auch