Varför använda systemd i stället för att bara köra appen i bakgrunden?

En bakgrundsprocess (med & eller nohup) dör vid omstart, kommer inte tillbaka om den kraschar och sprider sina loggar. En systemd-tjänst startar automatiskt vid uppstart, startar om vid fel och skickar sin utdata till journalctl. Det är det standardmässiga, tillförlitliga sättet att köra något långlivat på Linux.

Var hör unit-filer hemma?

Dina egna tjänster hör hemma i /etc/systemd/system/, en fil per tjänst, med ett namn som nånting.service. Efter att du skapat eller redigerat en, kör 'systemctl daemon-reload' så att systemd fångar upp ändringen, aktivera den sedan och starta den.

Vad gör 'Restart=always', och finns det nackdelar?

Den säger åt systemd att starta om tjänsten varje gång den avslutas, oavsett orsak — nyckeln till att hålla något igång. Den enda haken är en kraschloop: om appen misslyckas direkt vid start startar systemd om den om och om igen. Lägg till 'RestartSec=5' för att sprida ut försöken, och kolla loggarna för att åtgärda det underliggande felet.

Hur ser jag tjänstens loggar?

Använd 'journalctl -u yourservice -f' för att följa live-utdata, eller utan -f för att läsa historiken. systemd fångar stdout och stderr automatiskt, så du behöver inte koppla in loggfiler själv.

Ska tjänsten köras som root?

Helst inte. Skapa en dedikerad icke-root-användare och sätt 'User=' i uniten, så att ett intrång i appen inte lämnar över hela maskinen. Kör som root bara när tjänsten verkligen behöver det.

Så skapar du en systemd-tjänst för att hålla en app igång

Gör vilket skript eller vilken app som helst till en hanterad tjänst som startar vid uppstart, startar om om den kraschar och loggar till journalctl. Skriv en unit-fil, aktivera den och kontrollera dess status — standardsättet att köra något dygnet runt på Linux.

Att köra en app med & eller nohup går bra tills servern startas om, processen kraschar eller du vill hitta dess loggar — då faller det samman. systemd är standardsvaret: den startar din app vid uppstart, startar om den om den dör och fångar dess loggar. Att göra ett skript eller en binär till en hanterad tjänst är en liten fil.

1. Skriv en unit-fil

Skapa /etc/systemd/system/myapp.service:

[Unit]
Description=My application
After=network.target

[Service]
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/run.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Justera ExecStart, WorkingDirectory och User efter din app. Restart=always är det som håller den vid liv.

2. Skapa en dedikerad användare (rekommenderas)

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo chown -R myapp:myapp /opt/myapp

Att köra som icke-root-användare begränsar skadan om appen någon gång komprometteras.

3. Aktivera och starta den

sudo systemctl daemon-reload
sudo systemctl enable --now myapp

enable gör att den startar vid uppstart; --now startar den omedelbart.

4. Kontrollera status och loggar

sudo systemctl status myapp
journalctl -u myapp -f       # följ live-loggar

Vardagskommandon

sudo systemctl restart myapp   # starta om efter en ändring
sudo systemctl stop myapp      # stoppa den
sudo systemctl disable myapp   # sluta starta vid uppstart

Ärliga varningar

Kör daemon-reload efter att du redigerat en unit-fil, annars använder systemd den gamla versionen.
Se upp för kraschloopar. Om appen misslyckas direkt försöker Restart=always för evigt — RestartSec=5 sprider ut försöken; åtgärda grundfelet via loggarna.
Föredra en icke-root User= så att en komprometterad app inte äger hela servern.

Nästa steg

En systemd-tjänst är hur du håller vad som helst igång dygnet runt — till exempel en AI-agent som körs dygnet runt eller reläet bakom en självhostad RustDesk-server. Om din app i stället är containeriserad spelar Dockers --restart unless-stopped samma roll — se hur du installerar Docker.