Linux Boot-Befehle und Autostart

Inhaltsverzeichnis

Übersicht: Verschiedene Methoden
Systemd Services (Modern, Empfohlen)
Cron @reboot
rc.local (Legacy)
User-Autostart (Desktop)
Praktische Beispiele
Troubleshooting
Best Practices

Übersicht: Verschiedene Methoden

Linux bietet mehrere Wege, um Programme beim Systemstart automatisch auszuführen:

Methode	Wann verwenden	Vorteile	Nachteile
Systemd Services	Server, Daemons, wichtige Services	Modern, Logging, Auto-Restart, Abhängigkeiten	Komplexer
Cron @reboot	Einfache Skripte, einmalige Aktionen	Sehr einfach	Kein Logging, kein Auto-Restart
rc.local	Legacy-Systeme, schnelle Tests	Sehr simpel	Veraltet, nicht mehr empfohlen
Desktop Autostart	GUI-Programme für User	Für Desktop-Umgebungen	Nur nach User-Login

Empfehlung für Server/Dienste: Systemd Services

Empfehlung für einfache Skripte: Cron @reboot

Systemd Services (Modern, Empfohlen)

Systemd ist der moderne Standard-Init-System für die meisten Linux-Distributionen.

Grundkonzept

Service-Dateien definieren was, wann und wie gestartet wird
Automatisches Logging über journalctl
Abhängigkeiten (z.B. erst nach Netzwerk starten)
Auto-Restart bei Crash
Ressourcen-Limits (CPU, RAM)

Wo liegen Service-Dateien?

# System-Services (von Paketen installiert):
/lib/systemd/system/

# Eigene/Custom Services:
/etc/systemd/system/

# User-Services (pro Benutzer):
~/.config/systemd/user/

Grundstruktur einer Service-Datei

[Unit]
Description=Beschreibung des Service
After=network.target
# Optional: Requires=andere-services.service

[Service]
Type=simple
User=username
WorkingDirectory=/pfad/zum/arbeitsverzeichnis
ExecStart=/pfad/zum/befehl --mit --optionen
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Wichtige Direktiven erklärt

[Unit] Sektion

Description Beschreibung des Service (erscheint in systemctl status)

Description=Minecraft Server

After Startet NACH diesem Service/Target

# Nach Netzwerk:
After=network.target

# Nach NFS-Mount:
After=mnt-daten.mount

# Nach mehreren:
After=network.target network-online.target

Requires Service benötigt zwingend diesen anderen Service

Requires=postgresql.service

Wants Wünschenswert aber nicht zwingend

Wants=network-online.target

[Service] Sektion

Type Wie systemd den Start-Prozess behandelt

# simple: Hauptprozess ist ExecStart (Standard)
Type=simple

# forking: Prozess forkt und geht in Background
Type=forking

# oneshot: Einmalig ausführen, dann beenden
Type=oneshot

# notify: Prozess sendet Bereitschaftssignal
Type=notify

User / Group Unter welchem Benutzer läuft der Service

User=minecraft
Group=minecraft

WorkingDirectory Arbeitsverzeichnis (wie 'cd' vor dem Start)

WorkingDirectory=/opt/minecraft

ExecStart Der eigentliche Befehl zum Starten

ExecStart=/usr/bin/java -jar server.jar

# Mit Optionen:
ExecStart=/usr/bin/python3 /home/user/script.py --option value

ExecStartPre / ExecStartPost Befehle VOR/NACH dem Start

# Verzeichnis erstellen vor Start:
ExecStartPre=/bin/mkdir -p /var/run/myapp

# Aufräumen nach Start:
ExecStartPost=/bin/echo "Service gestartet" >> /var/log/myapp.log

ExecStop Befehl zum sauberen Beenden

ExecStop=/bin/kill -SIGTERM $MAINPID

Restart Wann automatisch neu starten

# Nie neu starten:
Restart=no

# Nur bei Fehler:
Restart=on-failure

# Immer (außer manuelles Stop):
Restart=always

# Nur bei abnormalem Exit:
Restart=on-abnormal

RestartSec Wartezeit vor Neustart (Sekunden)

RestartSec=10

Environment Umgebungsvariablen setzen

Environment="JAVA_HOME=/usr/lib/jvm/java-17"
Environment="PATH=/usr/local/bin:/usr/bin"

EnvironmentFile Variablen aus Datei laden

EnvironmentFile=/etc/default/minecraft

[Install] Sektion

WantedBy In welchem Target aktivieren

# Multi-User (Server ohne GUI):
WantedBy=multi-user.target

# Graphical (Desktop mit GUI):
WantedBy=graphical.target

# Default:
WantedBy=default.target

Service erstellen - Schritt für Schritt

1. Service-Datei anlegen

sudo nano /etc/systemd/system/mein-service.service

2. Inhalt schreiben

Siehe Beispiele unten.

3. Systemd neu laden

sudo systemctl daemon-reload

4. Service aktivieren (Autostart)

sudo systemctl enable mein-service.service

5. Service manuell starten (Test)

sudo systemctl start mein-service.service

6. Status prüfen

systemctl status mein-service.service

7. Logs anzeigen

journalctl -u mein-service.service -f

Service-Verwaltung - Wichtige Befehle

# Service starten
sudo systemctl start service-name.service

# Service stoppen
sudo systemctl stop service-name.service

# Service neu starten
sudo systemctl restart service-name.service

# Service neu laden (Config ohne Neustart)
sudo systemctl reload service-name.service

# Service aktivieren (Autostart beim Boot)
sudo systemctl enable service-name.service

# Service deaktivieren (kein Autostart)
sudo systemctl disable service-name.service

# Status anzeigen
systemctl status service-name.service

# Ist Service aktiv?
systemctl is-active service-name.service

# Ist Autostart aktiviert?
systemctl is-enabled service-name.service

# Alle Services auflisten
systemctl list-units --type=service

# Fehlgeschlagene Services
systemctl --failed

# Service-Datei anzeigen
systemctl cat service-name.service

# Service-Datei editieren (mit Override)
sudo systemctl edit service-name.service

Logs und Debugging

# Live-Logs anzeigen
journalctl -u service-name.service -f

# Letzte 50 Zeilen
journalctl -u service-name.service -n 50

# Logs seit heute
journalctl -u service-name.service --since today

# Logs zwischen Zeiträumen
journalctl -u service-name.service --since "2024-01-01 10:00" --until "2024-01-01 12:00"

# Alle Logs löschen (vorsichtig!)
sudo journalctl --vacuum-time=1d

Timer (zeitgesteuerte Services)

Systemd kann auch zeitgesteuert Services starten (Alternative zu Cron).

Service-Datei: /etc/systemd/system/backup.service

[Unit]
Description=Backup Script

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Timer-Datei: /etc/systemd/system/backup.timer

[Unit]
Description=Backup Timer
Requires=backup.service

[Timer]
OnCalendar=daily
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Aktivieren:

sudo systemctl daemon-reload
sudo systemctl enable backup.timer
sudo systemctl start backup.timer

# Timer-Status
systemctl list-timers

Cron @reboot

Cron ist ein klassischer Task-Scheduler. @reboot führt Befehle beim Systemstart aus.

Vorteile

Sehr einfach
Eine Zeile genügt
Keine Extra-Dateien

Nachteile

Kein automatisches Logging
Kein Auto-Restart bei Crash
Keine Abhängigkeiten

Crontab editieren

# Als root:
sudo crontab -e

# Als spezifischer User:
sudo crontab -u username -e

# Als aktueller User:
crontab -e

@reboot Syntax

@reboot /pfad/zum/befehl
@reboot /pfad/zum/script.sh >> /var/log/mein-script.log 2>&1

Beispiele

# Script beim Boot ausführen
@reboot /home/user/start-server.sh

# Mit Logging
@reboot /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# Warten vor Start (30 Sekunden)
@reboot sleep 30 && /home/user/script.sh

# Mit Umgebungsvariablen
@reboot export PATH=/usr/local/bin:$PATH && /home/user/app.sh

Crontab anzeigen

# Eigene Crontab
crontab -l

# Als root
sudo crontab -l

# Für anderen User
sudo crontab -u username -l

Crontab löschen

crontab -r

Wichtige Hinweise

1. Pfade sind wichtig!

Cron hat minimale PATH-Variable, also absolute Pfade verwenden:

# FALSCH:
@reboot python3 script.py

# RICHTIG:
@reboot /usr/bin/python3 /home/user/script.py

2. Logging hinzufügen

@reboot /home/user/script.sh >> /var/log/script.log 2>&1

>> - Anhängen (nicht überschreiben)
2>&1 - Stderr auch in Logfile

3. Arbeitsverzeichnis

@reboot cd /opt/myapp && ./start.sh

rc.local (Legacy)

Warnung: rc.local ist veraltet und wird in modernen Systemen oft nicht mehr unterstützt.

Wann noch verwenden?

Alte Systeme ohne Systemd
Sehr simple, einmalige Befehle
Schnelle Tests

rc.local erstellen (falls nicht vorhanden)

sudo nano /etc/rc.local

Inhalt:

#!/bin/bash

# Deine Befehle hier
/pfad/zum/befehl &

# Wichtig: exit 0 am Ende!
exit 0

Ausführbar machen

sudo chmod +x /etc/rc.local

rc.local als Systemd-Service aktivieren

Auf Systemd-Systemen muss rc.local als Service aktiviert werden:

sudo systemctl enable rc-local.service
sudo systemctl start rc-local.service

Beispiel

#!/bin/bash

# NFS-Mount nach Boot prüfen
sleep 10
mount -a

# Server starten
/home/minecraft/start.sh &

exit 0

Wichtig: & am Ende für Background-Prozesse!

User-Autostart (Desktop)

Für GUI-Anwendungen die nach User-Login starten sollen.

Autostart-Verzeichnis

~/.config/autostart/

Desktop-Datei erstellen

nano ~/.config/autostart/mein-programm.desktop

Inhalt:

[Desktop Entry]
Type=Application
Name=Mein Programm
Exec=/pfad/zum/programm
Terminal=false
X-GNOME-Autostart-enabled=true

Beispiel: Discord Autostart

[Desktop Entry]
Type=Application
Name=Discord
Exec=/usr/bin/discord
Terminal=false
X-GNOME-Autostart-enabled=true

GUI-Tools

GNOME: Tweaks → Startprogramme
KDE: Systemeinstellungen → Autostart
XFCE: Einstellungen → Sitzung und Startverhalten

Praktische Beispiele

Beispiel 1: Minecraft Server (Systemd) ⭐

Anwendungsfall: Minecraft Server der beim Boot startet, bei Crash neu startet, sauberes Logging

1. User erstellen (Sicherheit)

sudo useradd -r -m -d /opt/minecraft -s /bin/bash minecraft

2. Server vorbereiten

sudo mkdir -p /opt/minecraft
sudo chown minecraft:minecraft /opt/minecraft

# Server-Dateien nach /opt/minecraft kopieren
sudo -u minecraft cp server.jar /opt/minecraft/

3. Start-Script erstellen

sudo nano /opt/minecraft/start.sh

Inhalt:

#!/bin/bash
cd /opt/minecraft
/usr/bin/java -Xmx2G -Xms1G -jar server.jar nogui

Ausführbar machen:

sudo chmod +x /opt/minecraft/start.sh
sudo chown minecraft:minecraft /opt/minecraft/start.sh

4. Systemd-Service erstellen

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

Inhalt:

[Unit]
Description=Minecraft Server
After=network.target

[Service]
Type=simple
User=minecraft
Group=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/opt/minecraft/start.sh

# Bei Crash neu starten
Restart=on-failure
RestartSec=20

# Sauberes Herunterfahren
ExecStop=/bin/echo "stop" | /usr/bin/screen -S minecraft -p 0 -X stuff "%s"

# Ressourcen-Limits (optional)
MemoryLimit=3G
CPUQuota=200%

[Install]
WantedBy=multi-user.target

5. Service aktivieren

sudo systemctl daemon-reload
sudo systemctl enable minecraft.service
sudo systemctl start minecraft.service

6. Status prüfen

systemctl status minecraft.service
journalctl -u minecraft.service -f

Vorteile dieser Lösung:

✅ Startet automatisch beim Boot
✅ Neustart bei Crash (nach 20 Sekunden)
✅ Sauberes Logging via journalctl
✅ Läuft unter eigenem User (Sicherheit)
✅ Ressourcen-Limits möglich

Beispiel 2: Python Web-App mit Virtual Environment

Anwendungsfall: Flask/Django App beim Boot starten

1. Vorbereitung

sudo useradd -r -m -d /opt/webapp webapp
sudo mkdir -p /opt/webapp
sudo chown webapp:webapp /opt/webapp

2. Service-Datei

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

Inhalt:

[Unit]
Description=Python Web Application
After=network.target

[Service]
Type=simple
User=webapp
Group=webapp
WorkingDirectory=/opt/webapp

# Virtual Environment aktivieren und starten
ExecStart=/opt/webapp/venv/bin/python /opt/webapp/app.py

# Umgebungsvariablen
Environment="FLASK_ENV=production"
Environment="DATABASE_URL=postgresql://user:pass@localhost/db"

Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

3. Aktivieren

sudo systemctl daemon-reload
sudo systemctl enable webapp.service
sudo systemctl start webapp.service

Beispiel 3: Docker Container Autostart

Anwendungsfall: Docker Container beim Boot starten

Methode 1: Docker Restart-Policy (Empfohlen)

docker run -d --name mein-container --restart unless-stopped nginx

Restart-Policies:

no: Kein Autostart (Standard)
on-failure: Nur bei Fehler
always: Immer (auch nach Reboot)
unless-stopped: Immer, außer manuell gestoppt

Existierenden Container updaten:

docker update --restart unless-stopped container-name

Methode 2: Systemd-Service

sudo nano /etc/systemd/system/docker-nginx.service

Inhalt:

[Unit]
Description=Nginx Docker Container
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/docker start nginx-container
ExecStop=/usr/bin/docker stop nginx-container

[Install]
WantedBy=multi-user.target

Beispiel 4: NFS-Mount nach Boot prüfen

Anwendungsfall: Sicherstellen dass NFS-Mounts korrekt eingebunden sind

Methode 1: Systemd Dependency (Best)

Bereits in NFS-Anleitung erklärt:

# In /etc/fstab:
server:/share  /mnt/data  nfs4  _netdev,nofail  0  0

Methode 2: Check-Script (zusätzlich)

sudo nano /usr/local/bin/check-nfs.sh

Inhalt:

#!/bin/bash

# Warten auf Netzwerk
sleep 10

# NFS-Mounts prüfen und neu mounten falls nötig
if ! mountpoint -q /mnt/jellyfin-medien; then
    logger "NFS-Mount fehlt, versuche zu mounten..."
    mount /mnt/jellyfin-medien
    
    if [ $? -eq 0 ]; then
        logger "NFS-Mount erfolgreich"
    else
        logger "NFS-Mount fehlgeschlagen!"
    fi
fi

Ausführbar machen:

sudo chmod +x /usr/local/bin/check-nfs.sh

Cron @reboot:

sudo crontab -e

@reboot /usr/local/bin/check-nfs.sh

ODER Systemd-Service:

sudo nano /etc/systemd/system/check-nfs.service

[Unit]
Description=Check NFS Mounts
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/check-nfs.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Beispiel 5: Backup beim Boot

Anwendungsfall: Backup-Script einmal täglich beim ersten Boot

Script erstellen:

sudo nano /usr/local/bin/daily-backup.sh

Inhalt:

#!/bin/bash

BACKUP_DIR="/mnt/backups/daily"
DATE=$(date +%Y-%m-%d)
LOG_FILE="/var/log/backup.log"

# Prüfen ob heute schon Backup
if [ -f "$BACKUP_DIR/backup-$DATE.tar.gz" ]; then
    echo "$(date): Backup für heute existiert bereits" >> $LOG_FILE
    exit 0
fi

# Backup durchführen
echo "$(date): Starte Backup..." >> $LOG_FILE
tar -czf "$BACKUP_DIR/backup-$DATE.tar.gz" /home /etc /opt 2>> $LOG_FILE

if [ $? -eq 0 ]; then
    echo "$(date): Backup erfolgreich" >> $LOG_FILE
else
    echo "$(date): Backup fehlgeschlagen!" >> $LOG_FILE
    exit 1
fi

# Alte Backups löschen (älter als 7 Tage)
find $BACKUP_DIR -name "backup-*.tar.gz" -mtime +7 -delete
echo "$(date): Alte Backups gelöscht" >> $LOG_FILE

Ausführbar machen:

sudo chmod +x /usr/local/bin/daily-backup.sh

Cron @reboot:

sudo crontab -e

@reboot sleep 60 && /usr/local/bin/daily-backup.sh

Beispiel 6: Wake-on-LAN für andere Geräte

Anwendungsfall: Server weckt beim Boot andere Geräte (NAS, etc.)

wakeonlan installieren:

sudo apt install wakeonlan

Script erstellen:

sudo nano /usr/local/bin/wake-devices.sh

Inhalt:

#!/bin/bash

# Warten bis Netzwerk stabil
sleep 30

# NAS aufwecken
wakeonlan AA:BB:CC:DD:EE:FF

# Weiteres Gerät
wakeonlan 11:22:33:44:55:66

logger "Wake-on-LAN gesendet"

Ausführbar machen:

sudo chmod +x /usr/local/bin/wake-devices.sh

Systemd-Service:

sudo nano /etc/systemd/system/wake-devices.service

[Unit]
Description=Wake Devices on Boot
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wake-devices.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Aktivieren:

sudo systemctl daemon-reload
sudo systemctl enable wake-devices.service

Beispiel 7: VPN automatisch verbinden

Anwendungsfall: VPN-Verbindung beim Boot herstellen

Für OpenVPN:

sudo nano /etc/systemd/system/openvpn-autoconnect.service

[Unit]
Description=OpenVPN Autoconnect
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/client.conf
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

Für WireGuard:

WireGuard hat eigene Systemd-Integration:

sudo systemctl enable wg-quick@wg0.service

Beispiel 8: Screen/Tmux Session beim Boot

Anwendungsfall: Server-Prozess in Screen-Session starten (für manuelle Kontrolle)

Service mit Screen:

sudo nano /etc/systemd/system/minecraft-screen.service

[Unit]
Description=Minecraft Server in Screen
After=network.target

[Service]
Type=forking
User=minecraft
WorkingDirectory=/opt/minecraft

# Screen-Session starten
ExecStart=/usr/bin/screen -dmS minecraft /opt/minecraft/start.sh

# Screen-Session beenden
ExecStop=/usr/bin/screen -S minecraft -X quit

Restart=on-failure
RestartSec=20

[Install]
WantedBy=multi-user.target

Zugriff auf Screen:

sudo -u minecraft screen -r minecraft
# Detach: Ctrl+A, dann D

Beispiel 9: LED/GPIO beim Boot steuern (Raspberry Pi)

Anwendungsfall: Raspberry Pi LED beim Boot einschalten

Script:

sudo nano /usr/local/bin/led-on.sh

#!/bin/bash

# GPIO 18 als Output
echo "18" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio18/direction

# LED einschalten
echo "1" > /sys/class/gpio/gpio18/value

Systemd:

sudo nano /etc/systemd/system/led-on.service

[Unit]
Description=LED On at Boot
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/led-on.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Beispiel 10: Multi-Service Dependency

Anwendungsfall: Service A muss warten bis Service B bereit ist

Datenbank-Service (schon vorhanden):

postgresql.service

Web-App wartet auf Datenbank:

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

[Unit]
Description=Web Application
After=network.target postgresql.service
Requires=postgresql.service

[Service]
Type=simple
User=webapp
ExecStart=/opt/webapp/start.sh
Restart=always

[Install]
WantedBy=multi-user.target

Erkärung:

After=postgresql.service - Startet NACH PostgreSQL
Requires=postgresql.service - Stoppt wenn PostgreSQL stoppt

Troubleshooting

Service startet nicht

1. Status prüfen:

systemctl status service-name.service

Häufige Fehler:

# "ExecStart permission denied"
→ Script nicht ausführbar: chmod +x /pfad/zum/script

# "Failed to start: No such file or directory"
→ Pfad in ExecStart falsch oder User hat keine Rechte

# "Code=exited, status=1/FAILURE"
→ Script selbst hat Fehler, Logs prüfen

2. Logs anzeigen:

journalctl -u service-name.service -n 100 --no-pager

3. Service manuell testen:

# Als root:
sudo /pfad/zum/script.sh

# Als Service-User:
sudo -u username /pfad/zum/script.sh

4. SELinux/AppArmor prüfen (falls vorhanden):

# SELinux Status
getenforce

# Bei Problemen temporär deaktivieren (TEST):
sudo setenforce 0

Cron @reboot läuft nicht

1. Crontab prüfen:

crontab -l
sudo crontab -l

2. Cron-Logs prüfen:

grep CRON /var/log/syslog
# oder
journalctl -u cron

3. Pfade prüfen:

# PATH in Cron ist minimal!
# FALSCH:
@reboot python script.py

# RICHTIG:
@reboot /usr/bin/python3 /home/user/script.py

4. Test mit Logging:

@reboot /pfad/zum/script.sh >> /tmp/test.log 2>&1
# Dann /tmp/test.log prüfen nach Reboot

Script läuft manuell, aber nicht beim Boot

Häufige Ursachen:

1. Umgebungsvariablen fehlen

# In Script explizit setzen:
export PATH=/usr/local/bin:/usr/bin:/bin
export HOME=/home/username

2. Arbeitsverzeichnis falsch

# In Script:
cd /opt/myapp
./start.sh

3. Zu früh gestartet (Netzwerk nicht bereit)

# In Systemd: After=network-online.target
# In Cron: sleep 30 && /script.sh

4. User-spezifische Konfiguration

# .bashrc wird nicht geladen beim Boot
# Lösung: Pfade explizit im Script setzen

Service startet zu langsam

Problem: System bootet, aber Service braucht ewig

Lösung 1: Timeout erhöhen

[Service]
TimeoutStartSec=300

Lösung 2: Type ändern

# Wenn Script sofort in Background geht:
Type=forking

# Wenn Script einfach läuft:
Type=simple

Lösung 3: Dependencies prüfen

# Nur notwendige Dependencies:
After=network.target
# NICHT: After=multi-user.target (zu spät)

Service-Logging funktioniert nicht

Problem: journalctl zeigt nichts

Lösung:

# In Service-Datei:
StandardOutput=journal
StandardError=journal

# Oder in Datei:
StandardOutput=append:/var/log/myservice.log
StandardError=append:/var/log/myservice.log

Permission Denied Fehler

Problem: Service kann nicht starten wegen Berechtigungen

Checkliste:

# 1. Script ausführbar?
ls -la /pfad/zum/script.sh
sudo chmod +x /pfad/zum/script.sh

# 2. User hat Rechte auf WorkingDirectory?
sudo chown -R username:username /opt/myapp

# 3. User existiert?
id username

# 4. User kann Befehl ausführen?
sudo -u username /pfad/zum/befehl

Best Practices

✅ Immer machen:

1. Logging einrichten

# Systemd: Automatisch via journalctl
# Cron: >> /var/log/script.log 2>&1

2. Fehlerbehandlung im Script

#!/bin/bash
set -e  # Stop bei Fehler
set -u  # Stop bei undefinierten Variablen

3. Eigene User für Services

sudo useradd -r -s /bin/bash myservice

4. Test vor Aktivierung

# Systemd:
sudo systemctl start service.service  # Test
systemctl status service.service      # Prüfen
# Erst dann:
sudo systemctl enable service.service # Autostart

# Cron:
# Script manuell testen BEVOR in Crontab

5. Dokumentation

# In Service-Datei:
Description=Was macht dieser Service genau

# In Scripts:
# Kommentare was, warum, wie

❌ Vermeiden:

1. Root-Rechte ohne Grund

# SCHLECHT:
User=root

# BESSER:
User=myservice

2. Blocking ohne Timeout

# SCHLECHT:
while true; do sleep 1; done

# BESSER:
[Service]
Restart=always

3. Hardcoded Pfade

# SCHLECHT:
cd /home/user/app

# BESSER:
WorkingDirectory=/opt/app

4. Secrets in Service-Dateien

# SCHLECHT:
Environment="DB_PASSWORD=secret123"

# BESSER:
EnvironmentFile=/etc/myapp/secrets.conf
# Dann: chmod 600 /etc/myapp/secrets.conf

5. Keine Fehlerbehandlung

# SCHLECHT:
#!/bin/bash
rm -rf /important/data

# BESSER:
#!/bin/bash
set -e
if [ -d "/important/data" ]; then
    rm -rf /important/data
else
    echo "Verzeichnis existiert nicht!" >> /var/log/script.log
    exit 1
fi

🎯 Für Produktiv-Server:

1. Monitoring

# Systemd hat Health-Checks:
[Service]
ExecStartPost=/usr/local/bin/notify-started.sh

2. Resource-Limits

[Service]
MemoryLimit=2G
CPUQuota=150%
TasksMax=100

3. Security Hardening

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadOnlyPaths=/
ReadWritePaths=/var/lib/myapp

4. Graceful Shutdown

[Service]
TimeoutStopSec=30
KillMode=mixed
KillSignal=SIGTERM

🚀 Performance-Tipps:

1. Parallel starten (wenn möglich)

# Services die nicht voneinander abhängen:
# KEINE After= Dependencies setzen

2. Lazy-Loading

# Services erst bei Bedarf starten
[Unit]
After=network.target
# NICHT: Requires=network-online.target

3. Systemd Socket Activation

Services erst starten wenn Port angesprochen wird (fortgeschritten).

Zusammenfassung: Welche Methode wann?

Anwendungsfall	Empfohlene Methode	Grund
Server/Daemon dauerhaft	Systemd Service	Logging, Auto-Restart, Dependencies
Einmaliges Script beim Boot	Cron @reboot	Einfach, ausreichend
Minecraft/Game-Server	Systemd Service	Crash-Recovery wichtig
Docker Container	Docker Restart-Policy	Native Docker-Integration
Desktop-Programm	Desktop Autostart	Nach User-Login
Check-Script	Systemd OneShot	Dependencies, Logging
Legacy-System	rc.local	Wenn Systemd nicht verfügbar
Zeitgesteuert + Boot	Systemd Timer	Besser als Cron

Weiterführende Ressourcen

Systemd:

man systemd.service
man systemd.unit
man systemd.exec
Arch Wiki: systemd

Cron:

man crontab
man 5 crontab

Debugging:

# Systemd
systemd-analyze blame          # Was dauert beim Boot lange?
systemd-analyze critical-chain # Boot-Abhängigkeiten

# Journalctl
journalctl -b                  # Logs vom letzten Boot
journalctl --list-boots        # Alle Boots

Viel Erfolg beim Automatisieren! 🚀

Optimierte .bashrc-Konfiguration für Bash/Zsh

Linux: Inhalte von Ordnern nach Namensmustern verschieben

Linux: Leere Ordner finden und löschen

Serien-Dateien massenhaft umbenennen

Linux Boot-Befehle und Autostart

NFS und fstab - Vollständige Anleitung

NFS Mounts für Proxmox - Komplette Anleitung

Bash Scripting

Verstecken und Absichern

Linux Boot-Befehle und Autostart

Inhaltsverzeichnis

Übersicht: Verschiedene Methoden

Systemd Services (Modern, Empfohlen)

Grundkonzept

Wo liegen Service-Dateien?

Grundstruktur einer Service-Datei

Wichtige Direktiven erklärt

[Unit] Sektion

[Service] Sektion

[Install] Sektion

Service erstellen - Schritt für Schritt

1. Service-Datei anlegen

2. Inhalt schreiben

3. Systemd neu laden

4. Service aktivieren (Autostart)

5. Service manuell starten (Test)

6. Status prüfen

7. Logs anzeigen

Service-Verwaltung - Wichtige Befehle

Logs und Debugging

Timer (zeitgesteuerte Services)

Cron @reboot

Vorteile

Nachteile

Crontab editieren

@reboot Syntax

Beispiele

Crontab anzeigen

Crontab löschen

Wichtige Hinweise

rc.local (Legacy)

Wann noch verwenden?

rc.local erstellen (falls nicht vorhanden)

Ausführbar machen

rc.local als Systemd-Service aktivieren

Beispiel

User-Autostart (Desktop)

Autostart-Verzeichnis

Desktop-Datei erstellen

Beispiel: Discord Autostart

GUI-Tools

Praktische Beispiele

Beispiel 1: Minecraft Server (Systemd) ⭐

Beispiel 2: Python Web-App mit Virtual Environment

Beispiel 3: Docker Container Autostart

Beispiel 4: NFS-Mount nach Boot prüfen

Beispiel 5: Backup beim Boot

Beispiel 6: Wake-on-LAN für andere Geräte

Beispiel 7: VPN automatisch verbinden

Beispiel 8: Screen/Tmux Session beim Boot

Beispiel 9: LED/GPIO beim Boot steuern (Raspberry Pi)

Beispiel 10: Multi-Service Dependency

Troubleshooting

Service startet nicht

Cron @reboot läuft nicht

Script läuft manuell, aber nicht beim Boot

Service startet zu langsam

Service-Logging funktioniert nicht

Permission Denied Fehler

Best Practices

✅ Immer machen:

❌ Vermeiden:

🎯 Für Produktiv-Server:

🚀 Performance-Tipps:

Zusammenfassung: Welche Methode wann?

Weiterführende Ressourcen