Reinicia un servicio y comprueba que volvió de verdad

sudo systemctl restart nginx && systemctl is-active nginx reinicia el servicio e imprime una palabra que dice si de verdad está corriendo. El reinicio calla igual cuando todo va bien y cuando el proceso muere un segundo después, así que la comprobación tiene que ser un comando aparte — y is-active responde inactive también si escribiste mal el nombre del unit, que es donde casi todo el mundo se engaña.

1. Reinicia y comprueba en la misma línea

$ clai reinicia docker y dime si volvió→ sudo systemctl restart docker && systemctl is-active dockeractive

restart no imprime nada cuando tiene éxito, y el silencio no demuestra nada. is-active devuelve una sola palabra con código de salida 0, justo lo que quieres después de &&.

2. La trampa: un error en el nombre del unit

$ clai comprueba si el servicio nosuch está corriendo→ systemctl is-active nosuch.serviceinactive

Un unit que no existe responde inactive con código 4, no "unit not found". En un script eso se lee como "el servicio está parado" cuando en realidad te equivocaste al escribir. status es honesto: Unit nosuch.service could not be found.

3. Lo que status te está diciendo de verdad

$ clai muestra el estado del servicio docker→ systemctl status docker● docker.service - Docker Application Container Engine     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)     Active: active (running) since Mon 2026-08-24 14:15:54 +07; 3 days ago Invocation: ca41df104d0f46f5a69c964621baf011TriggeredBy: ● docker.socket       Docs: https://docs.docker.com

Dos líneas llevan el significado. Loaded dice que el archivo del unit se encontró, y enabled que arranca al inicio. Active trae el tiempo en marcha: si pone segundos y tú reiniciaste hace un minuto, el servicio se cayó y volvió solo.

4. Una comprobación para scripts, no para ojos

$ clai muestra el estado de docker en formato para máquinas→ systemctl show -p ActiveState,SubState,MainPID,NRestarts dockerActiveState=activeSubState=runningMainPID=5425NRestarts=0

show no formatea nada para humanos, así que sobrevive a las actualizaciones de systemd que reordenan la salida bonita. Un NRestarts que sube es la señal más rápida de que una política Restart= está tapando un ciclo de caídas.

5. Encuentra todo lo que ha fallado

$ clai muestra los servicios caídos→ systemctl --failed  UNIT              LOAD   ACTIVE SUB    DESCRIPTION● logrotate.service loaded failed failed Rotate log files

Corto y al grano. Para un unit concreto, systemctl is-failed <nombre> imprime failed y sale con código 0 cuando de verdad está en ese estado.

6. Limpia el estado failed

$ clai limpia el estado de error del servicio logrotate→ sudo systemctl reset-failed logrotate.service

Mientras no se limpie, el unit sigue en la lista --failed y el contador StartLimitBurst puede rechazar nuevos intentos con "start request repeated too quickly". reset-failed pone el contador a cero y lo saca de la lista.

Gotchas

• El silencio tras el reinicio no prueba nada. systemctl restart imprime vacío tanto si el servicio está sano como si murió al segundo. La verificación siempre es otro comando.
• is-active no distingue un error tipográfico de un servicio parado. Ambos responden inactive. Los códigos de salida difieren —4 para un unit inexistente— pero eso no se ve a simple vista, así que tira de status cuando la respuesta te sorprenda.
• restart no relee un archivo de unit modificado. Tras editar un .service hace falta sudo systemctl daemon-reload, o systemd arrancará la versión vieja y buscarás un fallo en una configuración ya corregida.

Related questions

¿Qué diferencia hay entre restart y reload? reload pide al propio servicio que relea su configuración sin cortar conexiones; restart mata el proceso y lo lanza de nuevo. Si el unit no soporta reload, reload-or-restart elige lo que haya.

¿Cómo veo por qué no arrancó? journalctl -u <nombre> -n 50 -o cat muestra las últimas líneas del log sin los prefijos de fecha — el motivo suele estar ahí.

¿Cómo sé que sobrevivirá a un reinicio de la máquina? systemctl is-enabled <nombre> responde enabled o disabled. Un servicio que ahora mismo corre puede estar disabled y no volver nunca tras el arranque.

See also

• journalctl: los logs de un servicio
• kill -9 no funciona
• Comprobar si un puerto está abierto

CliAI convierte "reinícialo y dime si volvió" en los dos comandos, y los muestra antes de ejecutar cualquiera. Instálalo en una línea.