Linux

On this Page

Latest News

Linux · Raspberry Pi · SSH

SSH-Key auf Windows, Tablet und Raspberry Pi einrichten

SSH-Schlüssel wirken am Anfang wie dunkle Konsolenmagie. Tatsächlich ist das Prinzip einfach: Der private Schlüssel bleibt auf dem eigenen Gerät, der öffentliche Schlüssel kommt auf jene Geräte, auf die man sich anmelden möchte.

Inhalte

1. Grundprinzip: privater und öffentlicher Schlüssel

Ein SSH-Key besteht immer aus zwei Teilen: einem privaten Schlüssel und einem öffentlichen Schlüssel.

Privater Schlüssel

Der private Schlüssel bleibt ausschließlich auf dem eigenen Gerät, also zum Beispiel auf dem Stand-PC, Laptop oder Tablet. Er ist der eigentliche Haustürschlüssel und darf nicht weitergegeben oder auf fremde Geräte kopiert werden. 

~/.ssh/id_ed25519

Öffentlicher Schlüssel

Der öffentliche Schlüssel darf auf Zielgeräte kopiert werden, etwa auf einen Raspberry Pi, einen Server oder ein anderes Linux-System mit SSH-Zugang. 

~/.ssh/id_ed25519.pub

Auf dem Zielgerät wird dieser öffentliche Schlüssel in die Datei authorized_keys eingetragen: 

~/.ssh/authorized_keys

Diese Datei ist gewissermaßen die Gästeliste des Zielsystems. Jeder dort eingetragene öffentliche Schlüssel darf sich anmelden, sofern der passende private Schlüssel auf dem Client vorhanden ist.

2. Braucht jedes Remote-Gerät einen eigenen Schlüssel?

Nicht zwingend. Sinnvoll ist meist folgende Regel: 

Ein Client-Gerät = ein eigenes Schlüsselpaar.
    Ein Remote-Gerät = enthält die erlaubten öffentlichen Schlüssel.

Beispiel:

  • Der Stand-PC hat seinen eigenen privaten und öffentlichen Schlüssel.
  • Das Tablet hat ebenfalls seinen eigenen privaten und öffentlichen Schlüssel.
  • Der Raspberry Pi enthält in authorized_keys beide öffentlichen Schlüssel.

Dadurch können sich sowohl Stand-PC als auch Tablet am Raspberry Pi anmelden, ohne dass private Schlüssel zwischen Geräten herumkopiert werden müssen.

3. Prüfen, ob auf Windows bereits ein SSH-Key vorhanden ist

Unter Windows funktioniert der Linux-Befehl ls -la in der klassischen PowerShell nicht wie erwartet. PowerShell kennt zwar ls als Alias, aber nicht die Linux-Option -la.

Der Versuch führt daher zu einer Fehlermeldung wie:

Get-ChildItem : Es wurde kein Parameter gefunden,
der dem Parameternamen "la" entspricht.

Stattdessen verwendet man unter Windows PowerShell: 

dir $env:USERPROFILE\.ssh

Oder gezielt für ED25519-Schlüssel: 

dir $env:USERPROFILE\.ssh\id_ed25519*

Wenn Dateien wie diese vorhanden sind, existiert bereits ein SSH-Key: 

id_ed25519
id_ed25519.pub

Der öffentliche Schlüssel kann mit folgendem Befehl angezeigt werden: 

cat ~/.ssh/id_ed25519.pub

Die Ausgabe sieht ungefähr so aus: 

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... benutzer@example.com

Diese Zeile darf auf das Zielgerät kopiert werden. Der private Schlüssel id_ed25519 bleibt dagegen auf dem Windows-PC.

4. Verbindung zum Raspberry Pi testen

Wenn der Raspberry Pi im Netzwerk unter dem Hostnamen sailsense.local erreichbar ist und der Benutzer user heißt, lautet der SSH-Befehl: 

ssh user@sailsense.local

Beim ersten Verbindungsaufbau erscheint normalerweise eine Meldung wie: 

The authenticity of host 'sailsense.local' can't be established.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Diese Meldung bedeutet: Der Computer kennt dieses Zielgerät noch nicht. Wenn man sicher ist, dass es sich um den eigenen Raspberry Pi handelt, bestätigt man mit: 

yes

Danach wird der Raspberry Pi in die Datei known_hosts eingetragen.

Wenn anschließend noch nach dem Passwort gefragt wird, ist der SSH-Key noch nicht richtig eingerichtet oder wird vom Raspberry Pi noch nicht akzeptiert.

5. Öffentlichen Schlüssel auf dem Raspberry Pi eintragen

Auf dem Raspberry Pi muss der öffentliche Schlüssel des Windows-PCs oder Tablets in die Datei authorized_keys eingetragen werden.

Zuerst am Raspberry Pi einloggen:

ssh user@sailsense.local

Dann das SSH-Verzeichnis anlegen beziehungsweise absichern:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Nun die Datei authorized_keys öffnen:

nano ~/.ssh/authorized_keys

Dort wird der öffentliche Schlüssel eingefügt. Eine solche Datei kann zum Beispiel so aussehen: 

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... standpc@example.com
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... [tablet@example.com](mailto:tablet@example.com)

Wichtig: Jeder öffentliche Schlüssel steht in einer eigenen Zeile.

Danach werden die Dateirechte gesetzt:

chmod 600 ~/.ssh/authorized_keys
6. Der typische Fehler: falsche Rechte auf ~/.ssh

Ein häufiger Fehler ist dieser Befehl: 

chmod 600 ~/.ssh

Das sieht harmlos aus, ist aber falsch. ~/.ssh ist ein Ordner. Ein Ordner braucht Ausführungsrechte, damit er betreten werden kann. Ohne dieses Recht kann SSH die Datei authorized_keys nicht zuverlässig lesen.

Die Folge kann eine merkwürdige Ausgabe sein: 

ls: cannot access '/home/user/.ssh/authorized_keys': Permission denied
d????????? ? ? ? ? ? .
-????????? ? ? ? ? ? authorized_keys

Das bedeutet sinngemäß: Das System sieht, dass dort etwas liegt, darf aber nicht sauber darauf zugreifen. SSH fällt dann auf die Passwortabfrage zurück.

Die korrekten Rechte lauten: 

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Zusätzlich kann man sicherstellen, dass der Benutzer auch wirklich Eigentümer der Dateien ist: 

chown -R user:user ~/.ssh

Danach sollte die Kontrolle so aussehen: 

ls -la ~/.ssh

Erwartete Ausgabe:

drwx------ 2 user user 4096 ... .
drwx------ 7 user user 4096 ... ..
-rw------- 1 user user  211 ... authorized_keys

Merksatz: 

.ssh              → 700
authorized_keys   → 600

7. Warum fragt SSH trotz eingetragenem Schlüssel noch nach dem Passwort?

Wenn SSH weiterhin nach dem Passwort fragt, obwohl der öffentliche Schlüssel eingetragen wurde, kommen meist diese Ursachen infrage:

  • Die Rechte von ~/.ssh oder authorized_keys sind falsch.
  • Der öffentliche Schlüssel wurde in die falsche Benutzerkennung eingetragen.
  • Der eingetragene öffentliche Schlüssel passt nicht zum privaten Schlüssel des Client-Geräts.
  • Der SSH-Client verwendet einen anderen Schlüssel als erwartet.
  • Der Inhalt von authorized_keys wurde beschädigt, etwa durch Zeilenumbrüche mitten im Schlüssel.

Wichtig ist besonders der Benutzername. Wer sich so verbindet: 

ssh user@sailsense.local

muss den Schlüssel hier eintragen: 

/home/user/.ssh/authorized_keys

Würde man sich als pi anmelden, müsste der Schlüssel stattdessen in: 

/home/pi/.ssh/authorized_keys

SSH ist hier pedantisch. Verschiedene Benutzer sind verschiedene Türen.

8. Verbindung mit Debug-Ausgabe prüfen

Wenn unklar ist, welcher Schlüssel verwendet wird, hilft die Debug-Ausgabe: 

ssh -v user@sailsense.local

Interessant sind Zeilen wie: 

Offering public key: C:\Users\julka\.ssh\id_ed25519

Das bedeutet: Der Client bietet diesen Schlüssel an.

Ideal wäre danach eine Meldung wie: 

Server accepts key

Wenn der Schlüssel angeboten, aber nicht akzeptiert wird, liegt das Problem fast immer auf dem Zielgerät: falscher Eintrag, falscher Benutzer, falsche Rechte oder falscher Besitzer.

Man kann einen bestimmten Schlüssel auch ausdrücklich angeben: 

ssh -i $env:USERPROFILE\.ssh\id_ed25519 user@sailsense.local

9. SSH-Key vom Tablet auf den Raspberry Pi einrichten

Auf einem Tablet hängt die genaue Vorgehensweise vom System ab. Unter Android wird häufig Termux verwendet. Dort kann man wie unter Linux arbeiten.

Zuerst prüfen, ob schon ein Schlüssel vorhanden ist:

ls -la ~/.ssh

Falls noch kein Schlüssel vorhanden ist, erzeugt man einen neuen:

ssh-keygen -t ed25519 -C "tablet"

Der Standardpfad kann in der Regel mit Enter übernommen werden: 

~/.ssh/id_ed25519

Danach wird der öffentliche Schlüssel angezeigt: 

cat ~/.ssh/id_ed25519.pub

Diese komplette Zeile wird anschließend auf dem Raspberry Pi in ~/.ssh/authorized_keys eingefügt.

Auf dem Raspberry Pi: 

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Danach kann vom Tablet getestet werden: 

ssh user@sailsense.local

10. Praktische SSH-Konfiguration

Damit man nicht jedes Mal den vollständigen Hostnamen und Benutzernamen eintippen muss, kann man auf dem Client eine SSH-Konfiguration anlegen.

Unter Linux, macOS oder Termux:

nano ~/.ssh/config

Unter Windows liegt die Datei hier:

C:\Users\BENUTZERNAME\.ssh\config

Beispielinhalt:

Host sailsense
HostName sailsense.local
User user
IdentityFile ~/.ssh/id_ed25519

Danach genügt: 

ssh sailsense

Falls sailsense.local im Netzwerk nicht zuverlässig aufgelöst wird, kann statt des Hostnamens auch die IP-Adresse eingetragen werden: 

Host sailsense
HostName 192.168.1.123
User user
IdentityFile ~/.ssh/id_ed25519

11. Passwortlogin erst später deaktivieren

Der Passwortlogin sollte erst deaktiviert werden, wenn die Anmeldung per SSH-Key sicher funktioniert. Sonst sperrt man sich schlimmstenfalls selbst aus. Das ist kein Sicherheitskonzept, sondern ein digitaler Tritt auf die eigene Harke.

Erst wenn der Login ohne Raspberry-Passwort funktioniert, kann man die SSH-Konfiguration bearbeiten: 

sudo nano /etc/ssh/sshd_config

Dort setzt man: 

PasswordAuthentication no

Danach wird SSH neu gestartet: 

sudo systemctl restart ssh

Wichtig: Vorher ein zweites Terminal offen lassen und testen, ob der Key-Login wirklich funktioniert.

12. Kurzfassung

  • Der private Schlüssel bleibt auf dem eigenen Gerät.
  • Der öffentliche Schlüssel kommt auf das Zielgerät.
  • Auf dem Zielgerät steht der öffentliche Schlüssel in ~/.ssh/authorized_keys.
  • Der Ordner ~/.ssh braucht die Rechte 700.
  • Die Datei authorized_keys braucht die Rechte 600.
  • Ein versehentliches chmod 600 ~/.ssh macht den Ordner unbetretbar.
  • Wenn SSH weiter nach dem Passwort fragt, mit ssh -v debuggen.

Für das konkrete Raspberry-Pi-Setup lautet die wichtigste Reparatur: 

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R user:user ~/.ssh

Danach sollte der Login vom Windows-PC oder Tablet per SSH-Key funktionieren.

Raspberry Pi Services mit systemd: Autostart, Kontrolle und Fehlersuche

Ein Raspberry Pi läuft oft ohne Bildschirm, Tastatur und Maus. Gerade bei Loggern, Sensorstationen, Heimautomationsprojekten oder kleinen Serverdiensten soll ein Programm automatisch starten, sobald der Pi hochfährt. Genau dafür verwendet man unter Raspberry Pi OS in der Regel systemd-Services.

Ein Service ist ein Hintergrunddienst: ein Programm, das vom Betriebssystem gestartet, überwacht, gestoppt und bei Bedarf automatisch neu gestartet werden kann. Statt ein Python-Skript nach jedem Neustart händisch per SSH zu starten, übernimmt systemd diese Aufgabe zuverlässig.

Was ist systemd?

systemd ist das Start- und Diensteverwaltungssystem vieler moderner Linux-Distributionen, darunter auch Raspberry Pi OS. Es kümmert sich darum, welche Prozesse beim Booten gestartet werden, in welcher Reihenfolge sie starten und wie sie überwacht werden.

Für eigene Projekte bedeutet das: Man schreibt eine kleine Service-Datei, legt darin fest, welches Programm gestartet werden soll, unter welchem Benutzer es laufen soll und was passieren soll, wenn es abstürzt.

Typische Einsatzfälle

  • Ein Python-Logger soll beim Booten automatisch starten.
  • Ein Webserver soll dauerhaft im Hintergrund laufen.
  • Ein Sensorprogramm soll nach einem Absturz neu gestartet werden.
  • Ein OLED-Display, GPS-Modul oder Wetterlogger soll ohne manuelles Eingreifen laufen.
  • Ein Raspberry Pi soll als headless Bordcomputer, Server oder Messgerät arbeiten.

Wichtige Begriffe

  • Unit: Allgemeine systemd-Konfigurationsdatei, z. B. Service, Timer oder Mount.
  • Service: Eine Unit, die ein Programm oder Skript startet.
  • Enable: Service wird beim Booten automatisch gestartet.
  • Start: Service wird jetzt sofort gestartet.
  • Stop: Service wird jetzt gestoppt.
  • Restart: Service wird neu gestartet.
  • Status: Aktueller Zustand des Services.
  • Journal: systemd-Logausgabe, abrufbar über journalctl.

Wo liegen eigene Service-Dateien?

Eigene systemd-Service-Dateien legt man üblicherweise hier ab: 

/etc/systemd/system/

Beispiel: 

/etc/systemd/system/sailsense.service

Der Dateiname ist gleichzeitig der Servicename. Aus sailsense.service wird also: 

systemctl status sailsense.service

Beispiel: Python-App als Service starten

Angenommen, das Projekt liegt unter: 

/home/user/sailsense

Die virtuelle Python-Umgebung liegt unter: 

/home/user/sailsense/.venv

Und die App wird manuell so gestartet: 

cd /home/user/sailsense
source .venv/bin/activate
PYTHONPATH=src python -m sailsense.app

Dann kann die passende Service-Datei so aussehen: 

[Unit]
Description=SailSense GPS Weather Logger
After=multi-user.target

[Service]
Type=simple
User=user
Group=user
SupplementaryGroups=dialout i2c gpio
WorkingDirectory=/home/user/sailsense
Environment=PYTHONPATH=/home/user/sailsense/src
ExecStart=/home/user/sailsense/.venv/bin/python -m sailsense.app
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Service-Datei anlegen

Eine neue Service-Datei erstellt man zum Beispiel mit: 

sudo nano /etc/systemd/system/sailsense.service

Danach den Inhalt einfügen, speichern und schließen.

Aufbau einer Service-Datei

[Unit]

Der Abschnitt [Unit] beschreibt den Dienst und seine Abhängigkeiten. 

[Unit]
Description=SailSense GPS Weather Logger
After=multi-user.target
  • Description: Kurzbeschreibung des Dienstes.
  • After: Gibt an, nach welchem Ziel oder Dienst dieser Service gestartet werden soll.

[Service]

Der Abschnitt [Service] legt fest, was genau gestartet wird. 

[Service]
Type=simple
User=user
Group=user
SupplementaryGroups=dialout i2c gpio
WorkingDirectory=/home/user/sailsense
Environment=PYTHONPATH=/home/user/sailsense/src
ExecStart=/home/user/sailsense/.venv/bin/python -m sailsense.app
Restart=on-failure
RestartSec=5
  • Type=simple: Der gestartete Prozess bleibt im Vordergrund und ist der Service.
  • User: Benutzer, unter dem das Programm läuft.
  • Group: Hauptgruppe des Prozesses.
  • SupplementaryGroups: Zusätzliche Gruppen, etwa für GPIO, I²C oder serielle Schnittstellen.
  • WorkingDirectory: Arbeitsverzeichnis des Programms.
  • Environment: Umgebungsvariable, hier z. B. PYTHONPATH.
  • ExecStart: Der eigentliche Startbefehl.
  • Restart=on-failure: Bei Fehler automatisch neu starten.
  • RestartSec=5: Fünf Sekunden warten, bevor neu gestartet wird.

[Install]

Der Abschnitt [Install] legt fest, wann der Dienst beim Booten aktiviert wird. 

[Install]
WantedBy=multi-user.target

multi-user.target entspricht grob einem normalen Mehrbenutzerbetrieb ohne grafische Oberfläche. Für headless Raspberry-Pi-Projekte ist das meistens passend.

systemd nach Änderungen neu laden

Nach jeder Änderung an einer Service-Datei muss systemd seine Konfiguration neu einlesen: 

sudo systemctl daemon-reload

Wenn man das vergisst, arbeitet systemd eventuell noch mit der alten Version der Datei. Das ist einer dieser kleinen Linux-Stolperdrähte, über die jeder einmal mit Würde fällt.

Service sofort starten

sudo systemctl start sailsense.service

Das startet den Service sofort, aber noch nicht automatisch beim nächsten Boot.

Service stoppen

sudo systemctl stop sailsense.service

Das stoppt den laufenden Dienst. Praktisch, wenn man am Code arbeiten möchte.

Service neu starten

sudo systemctl restart sailsense.service

Das ist nützlich nach Codeänderungen oder Konfigurationsänderungen.

Status abfragen

systemctl status sailsense.service

Typische Ausgabe: 

● sailsense.service - SailSense GPS Weather Logger
     Loaded: loaded (/etc/systemd/system/sailsense.service; enabled)
     Active: active (running)
   Main PID: 1234 (python)
      Tasks: 5
     Memory: 42.0M

Wichtig ist vor allem die Zeile: 

Active: active (running)

Das bedeutet: Der Service läuft.

Kurz prüfen, ob ein Service läuft

systemctl is-active sailsense.service

Mögliche Ausgaben:

  • active: läuft.
  • inactive: läuft nicht.
  • failed: ist fehlgeschlagen.

Autostart aktivieren

sudo systemctl enable sailsense.service

Damit wird der Dienst beim nächsten Boot automatisch gestartet.

Autostart deaktivieren

sudo systemctl disable sailsense.service

Der Dienst bleibt installierbar und kann manuell gestartet werden, startet aber nicht mehr automatisch beim Booten.

Prüfen, ob Autostart aktiv ist

systemctl is-enabled sailsense.service

Mögliche Ausgaben:

  • enabled: startet automatisch.
  • disabled: startet nicht automatisch.
  • static: kann nicht direkt aktiviert werden, wird aber möglicherweise von anderen Units verwendet.

Logs ansehen

systemd sammelt die Ausgaben eines Services im Journal. Alles, was das Programm mit print() ausgibt, kann dort erscheinen.

Live-Log

journalctl -u sailsense.service -f

-f bedeutet: neue Ausgaben live verfolgen. Beenden mit Strg+C.

Letzte 80 Zeilen

journalctl -u sailsense.service -n 80 --no-pager

Logs seit dem letzten Boot

journalctl -u sailsense.service -b --no-pager

Logs mit Zeitstempel

journalctl -u sailsense.service -n 100 --no-pager -o short-iso

Fehlerzustand zurücksetzen

Wenn ein Service fehlgeschlagen ist, kann systemd ihn als failed markieren. Nach der Fehlerbehebung kann man diesen Zustand zurücksetzen: 

sudo systemctl reset-failed sailsense.service

Service-Datei überprüfen

Vor dem Start kann man die Service-Datei formal prüfen: 

sudo systemd-analyze verify /etc/systemd/system/sailsense.service

Keine Ausgabe ist hier meist eine gute Nachricht.

Typischer Ablauf nach Änderung einer Service-Datei

sudo nano /etc/systemd/system/sailsense.service
sudo systemctl daemon-reload
sudo systemd-analyze verify /etc/systemd/system/sailsense.service
sudo systemctl restart sailsense.service
systemctl status sailsense.service

Typischer Ablauf nach Änderung des Python-Codes

Wenn nur der Python-Code geändert wurde, nicht die Service-Datei: 

sudo systemctl restart sailsense.service
journalctl -u sailsense.service -n 80 --no-pager

Service beim Entwickeln deaktivieren

Wenn man an der App arbeitet, ist es oft sinnvoll, den Service vorübergehend zu stoppen: 

sudo systemctl stop sailsense.service

Wenn man verhindern will, dass er beim nächsten Boot automatisch startet: 

sudo systemctl disable sailsense.service

Danach kann man die App manuell starten: 

cd /home/user/sailsense
source .venv/bin/activate
PYTHONPATH=src python -m sailsense.app

Service wieder aktivieren

sudo systemctl enable sailsense.service
sudo systemctl start sailsense.service

Häufige Fehler

1. Service-Datei hat falsche Abschnitte

Fehlerbild: 

Assignment outside of section

Ursache: In der Service-Datei fehlt wahrscheinlich ein Abschnitt wie [Unit], [Service] oder [Install].

2. ExecStart fehlt

Fehlerbild: 

Service has no ExecStart=

Ursache: Im Abschnitt [Service] fehlt der Startbefehl.

3. Falscher Python-Pfad

Fehlerbild: 

No such file or directory

Prüfen: 

ls -l /home/user/sailsense/.venv/bin/python

4. Modul wird nicht gefunden

Fehlerbild: 

ModuleNotFoundError

Ursache: Häufig fehlt PYTHONPATH.

In der Service-Datei: 

Environment=PYTHONPATH=/home/user/sailsense/src

5. Zugriff auf GPIO, I²C oder serielle Schnittstelle fehlt

Fehlerbild: 

Permission denied

Lösung: Benutzer in die nötigen Gruppen aufnehmen oder im Service zusätzliche Gruppen setzen. 

SupplementaryGroups=dialout i2c gpio

Danach: 

sudo systemctl daemon-reload
sudo systemctl restart sailsense.service

6. Service startet zu früh

Manchmal startet ein Dienst, bevor Hardware oder Netzwerk bereit ist.

Beispiele: 

After=network-online.target
Wants=network-online.target

Für Hardwareuhren oder spezielle Geräte können eigene Abhängigkeiten sinnvoll sein, zum Beispiel: 

Wants=rtc-hwclock.service
After=rtc-hwclock.service multi-user.target

Beispiel: Service mit RTC-Abhängigkeit

Wenn ein Projekt eine RTC verwendet, kann man sicherstellen, dass zuerst die Systemzeit aus der Hardware-Uhr gelesen wird. 

[Unit]
Description=SailSense GPS Weather Logger
Wants=rtc-hwclock.service
After=rtc-hwclock.service multi-user.target

[Service]
Type=simple
User=user
Group=user
SupplementaryGroups=dialout i2c gpio
WorkingDirectory=/home/user/sailsense
Environment=PYTHONPATH=/home/user/sailsense/src
ExecStart=/home/user/sailsense/.venv/bin/python -m sailsense.app
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Cheat Sheet: wichtigste Befehle

Aufgabe Befehl
Status anzeigen systemctl status sailsense.service
Starten sudo systemctl start sailsense.service
Stoppen sudo systemctl stop sailsense.service
Neu starten sudo systemctl restart sailsense.service
Autostart aktivieren sudo systemctl enable sailsense.service
Autostart deaktivieren sudo systemctl disable sailsense.service
Prüfen, ob aktiv systemctl is-active sailsense.service
Prüfen, ob Autostart aktiv systemctl is-enabled sailsense.service
Live-Log anzeigen journalctl -u sailsense.service -f
Letzte Logs anzeigen journalctl -u sailsense.service -n 80 --no-pager
systemd neu laden sudo systemctl daemon-reload
Service-Datei prüfen sudo systemd-analyze verify /etc/systemd/system/sailsense.service
Fehlerzustand zurücksetzen sudo systemctl reset-failed sailsense.service

Minimaler Wartungsablauf für eigene Raspberry-Pi-Projekte

  1. Service stoppen: sudo systemctl stop sailsense.service
  2. Code bearbeiten.
  3. App manuell testen.
  4. Service neu starten: sudo systemctl restart sailsense.service
  5. Status prüfen: systemctl status sailsense.service
  6. Logs prüfen: journalctl -u sailsense.service -n 80 --no-pager

Merksatz

Start startet jetzt. Enable startet künftig beim Booten. Status sagt, ob es lebt. Journalctl sagt, warum es gestorben ist.

↑ top ⌂ home ← back