Was ist eine systemd-Unit und warum dieser Builder?
Auf modernem Linux (Ubuntu, Debian, Fedora, Arch, Rocky, Alma...) ist systemd das Programm, das Services beim Boot startet, sie nach einem Crash neu startet und geplante Jobs ausfuehrt. Eine Unit-Datei ist eine kleine Textdatei in `/etc/systemd/system/`, die systemd sagt, *was* zu starten ist und *wie* sich das Ding verhalten soll.
Dieser Builder schreibt zwei Arten von Units fuer dich:
- `.service`-Dateien mit ExecStart fuer langlaufende Programme (eine Node-Web-App, ein Python-Worker, eine Datenbank).
- `.timer`-Dateien mit OnCalendar fuer Jobs, die nach Schedule laufen sollen (der moderne Ersatz fuer cron).
Preset waehlen, Felder ausfuellen, das Ergebnis in eine Datei unter `/etc/systemd/system/` kopieren, `sudo systemctl daemon-reload && sudo systemctl enable --now myapp.service` ausfuehren, und du bist fertig. Alles passiert im Browser, kein Upload, kein Account.
So benutzt du es
- Ein Preset waehlen, das deinem Fall aehnelt (Node Web-App, Python-Worker, One-Shot-Backup, Datenbank, Go-Binary, docker compose, Static Server). Das Formular fuellt mit sinnvollen Defaults, die du anpassen kannst.
- Den Unit-Namen setzen (`myapp` wird `myapp.service`), die Description (sichtbar in `systemctl status`) und die Abhaengigkeiten (After, Wants, Requires, fast jeder will `network-online.target`).
- Im Service-Bereich einen Type waehlen (`simple` fuer die meisten Apps, `oneshot` fuer Skripte, die laufen und enden, `forking` fuer Daemons, die in den Hintergrund forken), die User und Group zum Privileges-Droppen und ExecStart mit dem absoluten Pfad zu deinem Binary.
- Eine Restart-Policy waehlen. `on-failure` ist der sichere Default: systemd startet nur neu, wenn dein Programm mit non-zero endet oder crasht. `always` ist fuer langlebige Worker, die in jedem Fall wiederkommen muessen. RestartSec als Back-off (5 Sekunden ist okay) setzen.
- Environment-Variablen ergaenzen (NODE_ENV, DATABASE_URL...). Sensible (Passwoerter, Tokens) gehoeren stattdessen in `EnvironmentFile=`: in eine `chmod 600`-Datei ausserhalb der Unit legen.
- Optionales Hardening: `PrivateTmp`, `ProtectSystem`, `NoNewPrivileges` anschalten. Kostet nichts und begrenzt Schaden bei Kompromittierung. Der Builder erklaert jedes.
- Auf den .timer-Tab wechseln, wenn du einen geplanten Lauf statt (oder zusaetzlich zu) des langlaufenden Service willst. OnCalendar ausfuellen (z. B. `daily`, `Mon *-*-* 03:00:00`), Persistent anschalten, damit ein verpasster Lauf nach einem Reboot nachholt, Unit auf deinen Service zeigen lassen.
- Copy oder Download klicken. Datei nach `/etc/systemd/system/myapp.service` (und `myapp.timer` falls noetig) legen, dann `sudo systemctl daemon-reload`, `sudo systemctl enable --now myapp.service`, und Logs mit `journalctl -u myapp.service -f` ansehen.
Wann das nuetzlich ist
Sieben konkrete Situationen, in denen eine ordentliche systemd-Unit echte Zeit spart:
- Du hast ein Node-, Python- oder Go-Programm geschrieben und willst, dass es beim Boot startet und nach Crash neu startet. Eine `.service` in `/etc/systemd/system/` ablegen und `pm2`, `forever`, `screen` oder `nohup` vergessen.
- Du hast ein Skript, das nach Schedule laufen soll (naechtliches Backup, woechentlicher Report, stuendlicher Cache-Refresh). Ein `.timer`-plus-`.service`-Paar ist der moderne Ersatz fuer cron, und Logs gehen direkt nach journalctl.
- Du musst ein Programm als Non-Root-User mit kontrollierten Permissions laufen lassen. `User=` und `Group=` droppen Privileges; `ProtectSystem=strict`, `PrivateTmp=yes` und `NoNewPrivileges=yes` ergaenzen kostenlos Hardening.
- Du verwaltest eine kleine Flotte und willst dieselbe Service-Definition ueber Maschinen. Die Unit-Datei ist plain Text: in git versionieren, mit ansible / Makefile / scp deployen.
- Du brauchst, dass ein Service auf Netzwerk oder Datenbank wartet, bevor er startet. `After=network-online.target` und `Requires=postgresql.service` machen die Reihenfolge explizit.
- Ein docker-compose-Stack soll beim Boot starten. Ein Oneshot-`.service` mit `ExecStart=docker compose up -d` plus `Requires=docker.service` haendelt das sauber.
- Du willst zentrale Logs ohne Config. `StandardOutput=journal` (Default) heisst, `journalctl -u myapp` tailt dein Programm und `journalctl --since "1 hour ago"` ist deine einzige Suche.
Fragen und Antworten
systemd ist das Init-System auf den meisten modernen Linux-Distributionen (Ubuntu seit 15.04, Debian seit 8, RHEL/CentOS/Rocky seit 7, Fedora seit 15, Arch, openSUSE...). Es ist PID 1, der allererste Prozess, den der Kernel startet, verantwortlich fuers Booten, Starten von Services in der richtigen Reihenfolge, Restart nach Crash, geplante Jobs (Timer), Geraete-Management, Dateisystem-Mounts und Log-Sammlung. Wenn du `sudo systemctl restart nginx` tippst, sprichst du mit systemd. Eine Unit-Datei ist nur eine kleine INI-style-Textdatei, die systemd sagt, wie es einen Service, Timer, Socket oder Mount verwaltet.