Po co systemd zamiast po prostu uruchomić aplikację w tle?

Proces w tle (przez & lub nohup) umiera po restarcie, nie wraca po awarii i rozsypuje swoje logi. Usługa systemd startuje automatycznie przy rozruchu, uruchamia się ponownie po niepowodzeniu i wysyła wyjście do journalctl. To standardowy, niezawodny sposób uruchamiania czegoś długowiecznego w Linuksie.

Gdzie trafiają pliki unit?

Twoje własne usługi trafiają do /etc/systemd/system/, jeden plik na usługę, nazwany coś.service. Po utworzeniu lub edycji uruchom 'systemctl daemon-reload', aby systemd wychwycił zmianę, a następnie włącz i uruchom usługę.

Co robi 'Restart=always' i czy ma wady?

Każe systemd uruchamiać usługę ponownie za każdym razem, gdy się zakończy, z dowolnego powodu — to klucz do utrzymania czegoś w ruchu. Jedyny haczyk to pętla awarii: jeśli aplikacja natychmiast pada przy starcie, systemd bez przerwy ją restartuje. Dodaj 'RestartSec=5', by rozłożyć próby w czasie, i sprawdź logi, aby naprawić błąd źródłowy.

Jak zobaczyć logi usługi?

Użyj 'journalctl -u yourservice -f', by śledzić wyjście na żywo, lub bez -f, by czytać historię. systemd przechwytuje stdout i stderr automatycznie, więc nie musisz sam podłączać plików logów.

Czy usługa powinna działać jako root?

Raczej nie. Utwórz dedykowanego użytkownika bez uprawnień roota i ustaw 'User=' w unicie, aby przejęcie aplikacji nie oddawało całej maszyny. Uruchamiaj jako root tylko wtedy, gdy usługa naprawdę tego wymaga.

Jak utworzyć usługę systemd, by aplikacja działała nieprzerwanie

Zamień dowolny skrypt lub aplikację w zarządzaną usługę, która startuje przy rozruchu, uruchamia się ponownie po awarii i loguje do journalctl. Napisz plik unit, włącz go i sprawdź status — standardowy sposób, by coś działało 24/7 w Linuksie.

Uruchamianie aplikacji przez & lub nohup jest w porządku, dopóki serwer się nie zrestartuje, proces nie padnie albo nie zechcesz znaleźć jego logów — wtedy wszystko się rozpada. systemd to standardowa odpowiedź: startuje twoją aplikację przy rozruchu, uruchamia ją ponownie, gdy umrze, i przechwytuje jej logi. Zamiana skryptu lub pliku binarnego w zarządzaną usługę to jeden mały plik.

1. Napisz plik unit

Utwórz /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

Dostosuj ExecStart, WorkingDirectory i User do swojej aplikacji. Restart=always to to, co utrzymuje ją przy życiu.

2. Utwórz dedykowanego użytkownika (zalecane)

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

Uruchamianie jako użytkownik bez uprawnień roota ogranicza szkody, jeśli aplikacja kiedyś zostanie przejęta.

3. Włącz i uruchom usługę

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

enable sprawia, że startuje przy rozruchu; --now uruchamia ją natychmiast.

4. Sprawdź status i logi

sudo systemctl status myapp
journalctl -u myapp -f       # śledź logi na żywo

Codzienne polecenia

sudo systemctl restart myapp   # restart po zmianie
sudo systemctl stop myapp      # zatrzymaj ją
sudo systemctl disable myapp   # przestań startować przy rozruchu

Szczere ostrzeżenia

Uruchom daemon-reload po edycji pliku unit, inaczej systemd użyje starej wersji.
Uważaj na pętle awarii. Jeśli aplikacja natychmiast pada, Restart=always próbuje w nieskończoność — RestartSec=5 rozkłada próby w czasie; napraw błąd źródłowy dzięki logom.
Preferuj User= bez uprawnień roota, aby przejęta aplikacja nie była właścicielem całego serwera.

Kolejne kroki

Usługa systemd to sposób, w jaki utrzymujesz cokolwiek w ruchu 24/7 — na przykład agenta AI działającego całą dobę lub przekaźnik za samodzielnie hostowanym serwerem RustDesk. Jeśli twoja aplikacja jest zamiast tego skonteneryzowana, --restart unless-stopped Dockera pełni tę samą rolę — zobacz jak zainstalować Docker.