Zwei Befehle, die gleich klingen und Verschiedenes tun. Fast jedes "es lief, bis wir neu gestartet haben" ist genau das.

  • start - jetzt ausführen. Sagt nichts über das nächste Mal.
  • enable - beim Hochfahren ausführen. Startet ihn jetzt nicht.
  • enable --now - beides, und das war fast immer gemeint.
systemctl enable --now nginx
systemctl is-enabled nginx
systemctl is-active nginx

Den Zustand lesen

systemctl status php8.3-fpm
  • active (running) - wie erwartet.
  • active (exited) - er lief und ist fertig. Richtig für einen Einmal-Dienst, falsch für einen Daemon.
  • failed - er hat aufgehört und ist nicht wiedergekommen. Der Grund steht im Journal.
  • activating (auto-restart) - er hängt in einer Absturzschleife. Ihn noch einmal neu zu starten hilft nicht.

Warum er gescheitert ist

journalctl -u php8.3-fpm --since "1 hour ago" --no-pager | tail -40

reload, nicht restart

restart verwirft jede laufende Verbindung. reload liest die Konfiguration neu und behält sie. Bei einem Webserver oder einer Datenbank also reload, sofern die Änderung nicht wirklich einen Neustart braucht - und prüfen Sie zuerst die Konfiguration: nginx -t.

Eine eigene Unit

# /etc/systemd/system/queue-worker.service
[Unit]
Description=Queue worker
After=network.target mariadb.service

[Service]
User=www-data
ExecStart=/usr/bin/php8.3 /var/www/site/worker.php
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable --now queue-worker
daemon-reload nach dem Bearbeiten jeder Unit-Datei. Ohne das läuft systemd weiter mit der alten Definition, und Ihre Änderung scheint nichts bewirkt zu haben.