Due comandi che suonano uguali e fanno cose diverse. Quasi ogni "funzionava finché non abbiamo riavviato" è questo.

  • start - eseguilo adesso. Non dice nulla sulla prossima volta.
  • enable - eseguilo all'avvio. Adesso non lo avvia.
  • enable --now - tutti e due, ed è quasi sempre ciò che si intendeva.
systemctl enable --now nginx
systemctl is-enabled nginx
systemctl is-active nginx

Leggere lo stato

systemctl status php8.3-fpm
  • active (running) - come previsto.
  • active (exited) - è partito e ha finito. Corretto per un lavoro una tantum, sbagliato per un demone.
  • failed - si è fermato e non è tornato. Il motivo è nel journal.
  • activating (auto-restart) - è in ciclo di crash. Riavviarlo un'altra volta non servirà.

Perché è fallito

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

reload, non restart

restart lascia cadere ogni connessione in corso. reload rilegge la configurazione e le mantiene. Per un server web o un database usi reload, a meno che la modifica non richieda davvero un riavvio - e prima controlli la configurazione: nginx -t.

Una unit sua

# /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 dopo aver modificato qualsiasi file di unit. Senza, systemd sta ancora eseguendo la vecchia definizione e la sua modifica sembra non aver fatto nulla.