Deux commandes qui sonnent pareil et font des choses différentes. Presque tous les « ça marchait jusqu'à ce qu'on redémarre » sont cela.

  • start - le lancer maintenant. Ne dit rien de la fois suivante.
  • enable - le lancer au démarrage. Ne le démarre pas maintenant.
  • enable --now - les deux, ce que vous vouliez dire presque à chaque fois.
systemctl enable --now nginx
systemctl is-enabled nginx
systemctl is-active nginx

Lire l'état

systemctl status php8.3-fpm
  • active (running) - comme prévu.
  • active (exited) - il a tourné puis s'est terminé. Correct pour une tâche unique, faux pour un démon.
  • failed - il s'est arrêté et n'est pas revenu. La raison est dans le journal.
  • activating (auto-restart) - il boucle sur ses plantages. Le redémarrer encore n'y changera rien.

Pourquoi il a échoué

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

reload, pas restart

restart lâche toutes les connexions en cours. reload relit la configuration et les garde. Pour un serveur web ou une base, faites reload sauf si le changement exige vraiment un redémarrage - et vérifiez d'abord la configuration : nginx -t.

Une unité à vous

# /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 après avoir modifié n'importe quel fichier d'unité. Sans lui, systemd fait encore tourner l'ancienne définition et votre changement semble n'avoir rien fait.