Raspberry Pi Autostart

Passende Hardware im Überblick

Boards – jedes Modell startet Dienste automatisch:
Raspberry Pi 5 mit 8GB RAM – die Empfehlung für Dauerdienste (Link)*
Raspberry Pi 5 mit 16GB RAM – wenn viele Dienste parallel laufen (Link)*
Raspberry Pi 5 mit 4GB RAM – reicht für die meisten Skripte (Link)*
Raspberry Pi 4 Starter-Set mit 4GB (Link)*
Raspberry Pi Zero 2 W – der sparsame Dauerläufer (Link)*
db-tronic Pi 5 Komplett-Set mit Gehäuse und Netzteil (Link)*

Für den unterbrechungsfreien Dauerbetrieb:
Offizielles 27-W-Netzteil – stabile Versorgung ist Pflicht (Link)*
Geekworm X1200 USV – überbrückt Stromausfälle (Link)*
PiSugar 3 Plus – Akku-USV für mobile Projekte (Link)*
SanDisk Extreme A2 128GB – wenn es die Karte sein soll (Link)*
Geekworm X1001 M.2-HAT für den Pi 5 (Link)*
Crucial P310 NVMe SSD 500GB – schneller Systemstart (Link)*

Displays für Kiosk- und Anzeigeprojekte:
Offizielles 7-Zoll-Touchdisplay – die saubere Lösung (Link)*
ROADOM 10,1-Zoll-HDMI-Display – wenn es größer sein darf (Link)*
Hosyond 7-Zoll-DSI-Display (Link)*
3,5-Zoll-Display für den Pi 5 – kompakte Statusanzeige (Link)*

Kurz gesagt: Wie startet ein Programm beim Raspberry Pi automatisch?

Die Kurzfassung zum Raspberry Pi Autostart:

• Der saubere Weg: Ein eigener systemd-Service. Unit-Datei unter /etc/systemd/system/name.service anlegen, dann sudo systemctl enable --now name.service – fertig.
• Warum systemd: Nur damit gibt es Abhängigkeiten (erst Netzwerk, dann Dienst), automatischen Neustart nach Abstürzen und ein echtes Protokoll über journalctl.
• Die schnelle Alternative: crontab -e und eine Zeile mit @reboot – gut für kleine Skripte ohne Anspruch, aber ohne Neustartlogik und ohne Statusanzeige.
• Veraltet: /etc/rc.local gibt es in aktuellen Raspberry-Pi-OS-Versionen nicht mehr standardmäßig. Anleitungen, die das empfehlen, sind älter als Bookworm.
• Grafische Programme gehören nicht in einen systemd-Service, sondern in eine .desktop-Datei unter ~/.config/autostart/ – sonst fehlt die Bildschirmverbindung.
• Die drei häufigsten Fehler: relative Pfade, das falsche Python (Umgebung vergessen) und ein Dienst, der vor dem Netzwerk startet.

Warum der Raspberry Pi Autostart über systemd laufen sollte

Sobald ein Projekt den Bastelstatus verlässt, stellt sich dieselbe Frage: Wie kommt das eigene Skript nach einem Stromausfall von allein wieder hoch? Genau das leistet der Raspberry Pi Autostart – und dafür gibt es unter Raspberry Pi OS vier gängige Wege, die sich in Zuverlässigkeit deutlich unterscheiden.

systemd ist der Init-Prozess, der beim Booten ohnehin jeden Systemdienst startet – vom Netzwerk über SSH bis zum Drucker. Ein eigenes Skript dort einzuhängen bedeutet, dieselbe Maschinerie zu nutzen, die auch Docker oder den Webserver startet. Das klingt aufwendiger als eine Zeile in der Crontab, ist es aber nicht: Eine Unit-Datei hat zehn Zeilen und ist in fünf Minuten geschrieben.

Der Gewinn liegt in drei Punkten. Erstens Abhängigkeiten: Ein Dienst, der Daten ins Netz schickt, darf erst starten, wenn das Netzwerk wirklich steht. Zweitens Neustartverhalten: Stürzt das Skript ab, startet systemd es von selbst neu – bei einer Crontab-Zeile bleibt es einfach tot. Drittens Protokolle: Jede Ausgabe landet im Journal und ist mit einem Befehl abrufbar, statt in einer selbst gebastelten Logdatei zu verschwinden.

Die anderen Methoden haben trotzdem ihre Berechtigung. Für ein Skript, das einmalig eine Datei aufräumt, ist @reboot in der Crontab völlig ausreichend. Und für alles Grafische – Browser im Vollbild, Dashboard, MagicMirror – führt ohnehin kein Weg an der Autostart-Datei des Desktops vorbei, weil ein Systemdienst gar keinen Bildschirm sieht.

Raspberry Pi Autostart mit systemd einrichten – Schritt für Schritt

1. Skript testen: Bevor irgendetwas automatisiert wird, muss der Befehl von Hand laufen – mit vollständigem Pfad, etwa /home/pi/projekt/venv/bin/python /home/pi/projekt/main.py. Was manuell scheitert, scheitert als Dienst erst recht.
2. Unit-Datei anlegen: sudo nano /etc/systemd/system/meinprojekt.service. Der Name vor .service ist später der Name des Dienstes.
3. Inhalt schreiben: Die drei Abschnitte [Unit], [Service] und [Install] (Beispiel siehe unten). Wichtig sind User, WorkingDirectory und ein ExecStart mit absoluten Pfaden.
4. systemd informieren: sudo systemctl daemon-reload – ohne diesen Schritt kennt das System die neue Datei nicht. Das ist der mit Abstand häufigste Anfängerfehler.
5. Dienst aktivieren und starten: sudo systemctl enable --now meinprojekt.service. Das enable sorgt für den Start beim Booten, das --now startet ihn sofort.
6. Status prüfen: systemctl status meinprojekt.service. Dort steht active (running) – oder die Fehlermeldung, warum eben nicht.
7. Protokoll ansehen: journalctl -u meinprojekt.service -f zeigt die Ausgaben live mit, journalctl -u meinprojekt.service -b alles seit dem letzten Bootvorgang.
8. Neustart testen: sudo reboot und danach erneut den Status abfragen. Erst dieser Test beweist, dass der Autostart wirklich funktioniert.

So sieht eine vollständige Unit-Datei für ein Python-Programm aus:

[Unit]
  Description=Mein Messdienst
  After=network-online.target
  Wants=network-online.target

[Service]
  Type=simple
  User=pi
  WorkingDirectory=/home/pi/projekt
  ExecStart=/home/pi/projekt/venv/bin/python /home/pi/projekt/main.py
  Restart=always
  RestartSec=10

[Install]
  WantedBy=multi-user.target

Jede Zeile hat ihren Zweck: After und Wants mit network-online.target verzögern den Start, bis eine IP-Adresse vergeben ist – entscheidend für alles, was eine Verbindung braucht. User legt fest, unter welchem Konto das Programm läuft; ohne diese Zeile wäre es root, was für ein Bastelskript unnötig gefährlich ist. WorkingDirectory ersetzt das fehlende Arbeitsverzeichnis, damit relative Dateizugriffe im Skript weiterhin greifen. Restart=always mit RestartSec=10 holt den Dienst nach einem Absturz zurück, ohne das System mit Neustartversuchen im Sekundentakt zu fluten.

Autostart per crontab, rc.local und Desktop-Datei

Die schnellste Variante ist der Cronjob: crontab -e öffnen und eine Zeile ergänzen:

@reboot /usr/bin/python3 /home/pi/skript.py >> /home/pi/skript.log 2>&1

Das genügt für einfache Aufgaben. Nachteil: Cron startet die Zeile sehr früh im Bootvorgang, oft bevor Netzwerk oder Uhrzeit stehen. Als Notlösung hilft ein vorgeschaltetes @reboot sleep 30 && …, aber das ist Raten statt Wissen – genau diese Unsicherheit löst systemd mit echten Abhängigkeiten.

rc.local taucht in vielen älteren Anleitungen auf. In Raspberry Pi OS Bookworm ist die Datei nicht mehr vorgesehen; wer sie nutzen will, muss den Kompatibilitätsdienst selbst aktivieren. Für neue Projekte gibt es keinen Grund dazu.

Für grafische Programme ist eine Autostart-Datei zuständig. Anlegen unter ~/.config/autostart/meinprogramm.desktop:

[Desktop Entry]
  Type=Application
  Name=Mein Programm
  Exec=/usr/bin/chromium-browser --kiosk https://www.raspi-config.de/
  X-GNOME-Autostart-enabled=true

Kiosk-Modus: Browser im Vollbild automatisch starten

Ein sehr verbreiteter Anwendungsfall ist der Infoschirm: Der Pi bootet, meldet sich automatisch am Desktop an und öffnet eine Webseite im Vollbild – ein Wetter-Dashboard, eine Home-Assistant-Oberfläche oder eine Betriebsanzeige. Der ausführliche Weg dorthin steht in der Anleitung zum Kiosk-Modus, die Kurzfassung besteht aus drei Bausteinen.

Erstens die automatische Anmeldung: In raspi-config unter System Options – Boot / Auto Login die Variante „Desktop Autologin" wählen. Ohne angemeldeten Benutzer wird die Autostart-Datei nie ausgeführt.

Zweitens der Browserstart mit den passenden Schaltern: chromium-browser --kiosk --noerrdialogs --disable-infobars --disable-session-crashed-bubble. Die letzten beiden verhindern die lästige Meldung „Wiederherstellen?" nach einem harten Ausschalten – auf einem Gerät ohne Tastatur ein echtes Ärgernis.

Drittens der Bildschirmschoner, der nichts abschalten darf. Unter dem älteren X11-Desktop erledigen das xset s off und xset -dpms, unter dem heute üblichen Wayland-Desktop gehört die Einstellung in die Konfiguration der Oberfläche. Berichte aus der Community zeigen, dass genau dieser Punkt am häufigsten übersehen wird: Der Kiosk läuft perfekt – und ist nach zehn Minuten schwarz.

Dienste kontrollieren und Protokolle lesen

Ein automatisch startender Dienst ist nur so gut wie die Möglichkeit, ihm beim Scheitern zuzusehen. Diese Befehle decken den Alltag ab und gehören neben die üblichen Raspberry-Pi-Befehle:

Wer den Pi ohne Monitor betreibt, arbeitet dabei über SSH – und sollte dem Gerät vorher eine feste IP-Adresse geben, damit es nach jedem Neustart unter derselben Adresse erreichbar bleibt.

Fehler und Stolpersteine beim Autostart

• Relative Pfade: Ein Dienst startet ohne das gewohnte Heimatverzeichnis. ./daten.csv zeigt dann ins Leere. Entweder absolute Pfade verwenden oder WorkingDirectory setzen – am besten beides.
• Falsches Python: Wer mit einer virtuellen Umgebung arbeitet, muss deren Interpreter direkt angeben (/pfad/venv/bin/python). Ein schlichtes python3 nimmt das Systempython, dem sämtliche Pakete fehlen – der Klassiker bei GPIO-Skripten.
• Dienst startet vor dem Netzwerk: Ohne Wants=network-online.target läuft der Dienst los, bevor eine IP-Adresse vergeben ist, und beendet sich mit einem Verbindungsfehler. Das fällt oft erst nach Wochen auf – nämlich beim ersten Stromausfall.
• daemon-reload vergessen: Änderungen an der Unit-Datei greifen erst nach sudo systemctl daemon-reload. Wer das überspringt, testet weiter die alte Fassung.
• Falsche Rechte: Läuft der Dienst als pi, muss dieses Konto Zugriff auf alle beteiligten Dateien und Geräte haben – bei GPIO, I2C oder seriellen Schnittstellen ist dafür die passende Gruppenmitgliedschaft nötig.
• Endlose Neustartschleife: Restart=always ohne RestartSec lässt ein defektes Skript hunderte Male pro Minute starten. Zehn Sekunden Pause reichen und halten das Protokoll lesbar.
• Grafisches Programm als Systemdienst: Ein Browser oder Fenster startet aus einem systemd-Service heraus nicht, weil die Bildschirmverbindung fehlt. Solche Programme gehören in die Autostart-Datei des Desktops.

Häufige Fragen zum Autostart auf dem Raspberry Pi

Wie starte ich ein Python-Skript beim Booten automatisch?
Am zuverlässigsten mit einem systemd-Service, in dem der vollständige Pfad zum Interpreter und zum Skript steht. Für einen einmaligen Aufruf ohne Überwachung genügt eine @reboot-Zeile in der Crontab.

Warum läuft mein Skript von Hand, aber nicht als Dienst?
In neun von zehn Fällen liegt es an der Umgebung: fehlendes Arbeitsverzeichnis, relative Pfade oder eine nicht aktivierte Python-Umgebung. journalctl -u name -b zeigt die konkrete Fehlermeldung.

Wie deaktiviere ich einen Autostart wieder?
Bei systemd mit sudo systemctl disable name, bei Cron durch Löschen der Zeile in crontab -e, bei grafischen Programmen durch Entfernen der .desktop-Datei aus ~/.config/autostart/.

Was ist der Unterschied zwischen enable und start?
start startet den Dienst jetzt, enable sorgt für den Start beim nächsten Bootvorgang. Beides zusammen erledigt enable --now – wer nur start aufruft, wundert sich nach dem Neustart.

Gibt es rc.local noch?
In aktuellen Versionen von Raspberry Pi OS ist die Datei nicht mehr Teil des Standardsystems. Bestehende Skripte lassen sich weiterbetreiben, für neue Projekte ist systemd die richtige Wahl.

Wie verzögere ich den Start eines Dienstes?
Sauber über Abhängigkeiten wie After=network-online.target, notfalls über ExecStartPre=/bin/sleep 20. Feste Wartezeiten sind aber immer nur ein Behelf.

Startet ein Docker-Container von allein wieder?
Ja, dafür genügt restart: unless-stopped in der Compose-Datei – Docker selbst wird von systemd gestartet und bringt seine Container mit hoch. Details dazu stehen in der Docker-Anleitung.

Fazit

Für den Raspberry Pi Autostart gibt es vier Wege, aber nur einen, der auf Dauer trägt: Unsere klare Empfehlung ist der systemd-Service. Zehn Zeilen in einer Unit-Datei liefern das, was Crontab und rc.local prinzipbedingt nicht können – definierte Abhängigkeiten, automatischen Neustart nach Abstürzen und ein durchsuchbares Protokoll. Der einzige Fall, in dem eine andere Methode gewinnt, ist die grafische Oberfläche: Browser, Dashboard und Kiosk-Betrieb gehören in eine .desktop-Datei, weil ein Systemdienst keinen Bildschirm kennt. Wer beides sauber trennt und beim Einrichten konsequent absolute Pfade verwendet, hat einen Pi, der nach jedem Stromausfall genau dort weitermacht, wo er aufgehört hat – ganz ohne Tastatur und Monitor.

* = Affiliate Link (raspi-config.de ist Teilnehmer des Partnerprogramms von Amazon EU, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu Amazon.de Werbekostenerstattung verdient werden kann.)