Antes de reiniciar un servicio de Linux, siempre prefiero ver qué se está ejecutando realmente. En una máquina con sistemad, sistemactl Ya proporciona prácticamente todo lo que necesitas: servicios activos, servicios fallidos, inicio automático, estado detallado y los últimos mensajes útiles.
Esto es especialmente cierto en un servidor. Reiniciar nginx, ssh, mariadb Un servicio empresarial, sin comprobar su estado, puede finalizar una sesión, interrumpir un sitio web u ocultar un error de configuración. Aquí encontrará los comandos necesarios para listar correctamente los servicios de Linux, filtrar la información relevante y decidir si es realmente necesario reiniciar el sistema.
Enumera los servicios activos con systemctl
El comando más directo es mostrar las unidades de tipo de servicio cargadas actualmente:
systemctl list-units --type=serviceObtendrás una lista con varias columnas. Las más importantes son: CARGA, ACTIVO, SUB Y DESCRIPCIÓNEn la práctica, me fijo principalmente en ACTIVO Y SUB Un servicio puede cargarse, pero detenerse por error o simplemente finalizarse porque ese es su comportamiento normal.
Para ver únicamente los servicios que se están ejecutando actualmente:
systemctl list-units --type=service --state=runningPara mostrar los servicios que están suspendidos:
systemctl list-units --type=service --state=exitedNo se asuste si ve servicios en salióAlgunos procesos inician una acción breve y luego se detienen normalmente. Es necesario examinar el servicio en cuestión antes de concluir que existe un problema.
Ver servicios fallidos
Cuando una máquina falla, comience con este comando:
systemctl --failedMuestra las unidades que systemd considera que están fallando. Esto es más útil que un reinicio a ciegas, ya que permite ver inmediatamente el nombre exacto del servicio que se debe inspeccionar.
Ejemplo :
systemctl status ssho, según la distribución:
systemctl status sshdLa salida muestra el estado del servicio, el archivo de unidad que se está utilizando, el PID principal si el servicio está en ejecución y las últimas líneas del registro. Si necesita diagnosticar un inicio fallido, estas pocas líneas suelen proporcionar la primera pista.
Determinar si un servicio se inicia automáticamente
Un servicio puede estar activo ahora sin haber sido activado al iniciarse. Lo contrario también es posible: un servicio puede estar activado, pero detenido porque falló o porque aún no se ha iniciado.
Para listar los archivos de unidad y su estado al inicio:
systemctl list-unit-files --type=serviceLos estados más comunes son:
activado: el servicio está diseñado para iniciarse automáticamente;desactivado: no se inicia automáticamente;estático: no se activa directamente, sino que puede ser llamado por otra unidad;enmascarado: el servicio está bloqueado intencionalmente.
Para consultar un servicio específico:
systemctl está habilitado nginx
systemctl está activo nginxEl primer comando responde en relación con el inicio automático. El segundo responde en relación con el estado actual. Ninguna de las dos informaciones reemplaza a… estado del sistemapero resultan útiles en un script de control o en una lista de verificación rápida.
Filtra la lista sin perderte en ella.
En un servidor con algo de actividad, la lista completa se vuelve larga rápidamente. Puede filtrar con grep Cuando buscas una familia de servicios:
systemctl list-units --type=service | grep sshPara mostrar solo los servicios activos sin paginador:
systemctl list-units --type=service --state=running --no-pagerY si desea una salida más legible en un ticket o un diagnóstico breve:
systemctl list-units --type=service --state=failed --no-pagerEn un servidor remoto, a menudo añado --sin localizadorEsto evita que te quedes atascado en la pantalla interactiva, especialmente cuando trabajas rápidamente a través de SSH.
Lea los registros antes de reiniciar.
Si un servicio está experimentando un error, no lo inicie. ReanudarPrimero, miren los periódicos:
journalctl -u nginx -n 50 --no-pagerPara seguir los registros en directo:
journalctl -u nginx -fAquí es donde suele aparecer un error, como un puerto ya en uso, un archivo de configuración no válido, un permiso incorrecto o una dependencia faltante. Si no estás familiarizado con los registros de systemd, también he incluido más detalles. Cómo leer los registros del último arranque de Linux usando journalctl.
Reinicie solo después de que se hayan completado las comprobaciones.
Una vez identificado el servicio, compruebe su configuración cuando la herramienta lo permita. Por ejemplo, para Nginx:
nginx -tPara SSH, tenga aún más cuidado. Si reinicia el servicio incorrecto o si la configuración es inválida, puede perder el acceso remoto. Mantenga una sesión abierta, revise el cortafuegos y, a continuación, utilice SSH. recargar cuando eso sea suficiente.
sudo systemctl reload ssh
sudo systemctl restart sshel orden recargar Solicita al servicio que vuelva a leer su configuración sin detenerlo por completo, si el servicio lo admite. Reanudar El servicio se interrumpe y luego se reinicia. Esto no supone el mismo nivel de riesgo.
Si ha modificado un archivo de unidad systemd, considere también la diferencia con recarga de demoniosExpliqué este caso por separado en el artículo. Systemctl daemon-reload: ¿cuándo debería utilizarse realmente en Linux?.
La mini lista de verificación antes de tocar un servicio
- Enumere los servicios relevantes con
systemctl list-units --type=service. - Compruebe si hay errores con
systemctl --failed. - Lea el estado preciso con
systemctl status nombre-del-servicio. - Mira los registros con
journalctl -u nombre-del-servicio. - Compruebe la configuración si el servicio ofrece un comando de validación.
- Preferir
recargartieneReanudarcuando se tolera y es suficiente.
la documentacion de sistemactl Se detallan todas las opciones, pero para el uso diario, estos comandos ya cubren la mayoría de los diagnósticos. Mi consejo: si no sabes por qué se reinicia un servicio, no lo reinicies todavía. Enumera los problemas, lee los registros y luego actúa.