En cualquier Linux moderno, un servicio que no arranca ya ha dejado escrito exactamente por qué. Está en el diario, y si la gente dice que no hay nada en los registros es porque ejecutó journalctl sin argumentos y se rindió ante el tamaño.

Las cinco que hacen el trabajo

journalctl -u nginx -n 50 --no-pager   # the last 50 lines for one unit
journalctl -u nginx -f                # follow it live
journalctl -u nginx --since "10 min ago"
journalctl -p err -b                  # errors only, this boot
journalctl -b -1                      # the boot BEFORE this one
-b -1 es a la que hay que echar mano tras un reinicio inexplicado: muestra lo que decía la máquina justo antes de caerse, que el arranque actual no contiene.

Cuando un servicio no arranca

systemctl status app --no-pager -l
journalctl -u app -n 100 --no-pager

status muestra el código de salida y las últimas líneas; el diario muestra el resto. Una unidad que falla al instante es casi siempre una ruta, un permiso o un puerto ya ocupado, y las tres cosas lo dicen con todas las letras.

El diario en el disco

Por defecto puede ser volátil: se guarda en memoria y se pierde al reiniciar, que es justo cuando lo necesita. Hágalo persistente.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage

Evite que llene el disco

# /etc/systemd/journald.conf
SystemMaxUse=500M
MaxRetentionSec=1month
Una aplicación que escribe su propio archivo -los registros de acceso de Nginx, los de consultas lentas de PHP-FPM- no está en el diario. Esos están en /var/log y rotan aparte; vea la rotación de registros.