Administrar Linux no consiste solo en memorizar comandos. Muchas de las diferencias entre resolver una incidencia en diez minutos o pasar una hora probando cosas aparecen en pequeños hábitos: mirar antes de tocar, comprobar qué ha cambiado, guardar evidencias antes de reiniciar y verificar el resultado de cada acción. Son prácticas sencillas que sirven tanto para quien mantiene un servidor doméstico como para equipos responsables de sistemas en producción.

Las claves de los buenos hábitos en Linux en 20 segundos

• Antes de reiniciar un servicio conviene revisar su estado y sus últimos registros.
• journalctl, ss, findmnt o vmstat ayudan a comprobar qué ocurre realmente.
• Los comandos destructivos deberían probarse primero con opciones como --dry-run.
• En automatización hay que comprobar errores y no depender del entorno de la terminal.
• Documentar incidencias evita investigar dos veces el mismo problema.

No hace falta instalar una plataforma de observabilidad para aplicar estas prácticas. Muchas de las herramientas necesarias forman parte de cualquier distribución moderna.

La idea central es cambiar una costumbre muy humana: dejar de probar soluciones antes de haber entendido el problema.

Antes de arreglar Linux, hay que preguntarle qué está pasando

Cuando una página web deja de responder, una base de datos parece bloqueada o un servicio se cae, reiniciar suele parecer la opción más rápida.

Por ejemplo:

systemctl restart nginx

A veces funciona.

El problema es que también cambia el estado del sistema y puede hacer desaparecer información útil para descubrir qué había ocurrido.

Antes del reinicio resulta mucho más interesante ejecutar:

systemctl status nginx

Después se pueden revisar los mensajes recientes:

journalctl -u nginx --since "-15 min"

Y comprobar si realmente existe algún proceso escuchando en los puertos esperados:

ss -lntp

Un vistazo adicional a almacenamiento y memoria completa una primera fotografía:

df -h

free -h

En menos de un minuto ya se dispone de bastante información.

Esta forma de trabajar introduce una regla sencilla: primero observar, después intervenir.

Preguntar qué cambió suele ahorrar mucho tiempo

Un servidor que funcionaba ayer y hoy no lo hace rara vez ha cambiado por arte de magia.

Puede haber ocurrido una actualización, un despliegue, un cambio de certificado, una modificación de configuración o una nueva regla de firewall.

Por eso merece la pena empezar por:

git status

git diff

Si la configuración está versionada, también puede revisarse qué commits aparecieron recientemente:

git log --since="2 days ago" --oneline

En servidores Debian o Ubuntu pueden consultarse igualmente los registros de APT y dpkg; las distribuciones basadas en RPM disponen de historiales equivalentes.

En entornos profesionales, el historial de despliegues de CI/CD, Ansible o cualquier plataforma de automatización puede ser todavía más revelador.

Preguntar “¿qué ha cambiado?” suele ser una estrategia mejor que buscar inmediatamente una causa compleja.

journalctl es mucho más útil cuando se filtra

Un error habitual es ejecutar:

journalctl -xe

y encontrarse con cientos o miles de líneas.

El problema puede estar ahí, pero escondido.

Resulta más útil delimitar lo que se busca.

Solo los registros de nginx:

journalctl -u nginx

Los últimos veinte minutos:

journalctl -u nginx --since "-20 min"

Errores del arranque actual:

journalctl -p err -b

Mensajes del kernel:

journalctl -k -b

Y hay una opción especialmente interesante cuando un servidor acaba de reiniciarse:

journalctl -b -1

Permite consultar el arranque anterior.

Así se puede investigar qué estaba ocurriendo antes de que el sistema volviera a ponerse en marcha.

Comprobar los servicios fallidos lleva segundos

Otro comando pequeño que puede descubrir problemas olvidados es:

systemctl --failed

Muestra las unidades de systemd que han terminado en estado failed.

Puede aparecer un servicio auxiliar, un montaje, una tarea de arranque o algún componente que todavía no ha producido un fallo visible para los usuarios.

Conviene inspeccionarlo antes de borrar ese estado con:

systemctl reset-failed

De nuevo se aplica la misma idea: no eliminar una pista antes de entenderla.

Red, discos y rendimiento: comprobar lo que realmente está ocurriendo

La configuración de una aplicación dice cómo debería comportarse.

Linux puede mostrar cómo está comportándose realmente.

Esa diferencia es importante.

ss confirma qué puertos están escuchando

Si una aplicación supuestamente funciona en el puerto 443, se puede comprobar:

ss -lntp

El comando muestra sockets TCP en escucha y, con permisos suficientes, los procesos relacionados.

Para UDP:

ss -lunp

Y para conexiones TCP activas:

ss -tnp

Esto permite distinguir varios problemas.

Si no aparece nada en :443, el servicio probablemente no está escuchando.

Si aparece:

127.0.0.1:443

pero debería ser accesible desde otra máquina, quizá esté enlazado únicamente a localhost.

Antes de sospechar de routers, firewalls externos o proveedores cloud conviene confirmar qué ocurre en el propio servidor.

df no cuenta toda la historia del almacenamiento

Casi cualquier administrador conoce:

df -h

Es excelente para conocer el espacio utilizado.

Pero un sistema moderno puede tener particiones, volúmenes LVM, discos cloud, NFS, bind mounts o almacenamiento utilizado por contenedores.

Para ver los dispositivos:

lsblk

Para inspeccionar montajes:

findmnt

Y para responder a una pregunta muy concreta como “¿dónde está realmente /var/lib/docker?”:

findmnt --target /var/lib/docker

Esta combinación ayuda a distinguir entre disco físico, partición, sistema de archivos y punto de montaje, conceptos relacionados pero no idénticos.

También evita errores peligrosos cuando existen varios discos con nombres similares.

Una captura puntual de CPU no siempre explica un problema

top muestra lo que ocurre ahora.

Pero una máquina puede tener un problema que aparece durante cinco segundos cada minuto.

Ahí empiezan a resultar útiles herramientas como:

vmstat 1

Cada segundo mostrará información de CPU, memoria, procesos, swap y actividad de entrada/salida.

Si está instalado sysstat, otra herramienta práctica es:

iostat -xz 1

Permite observar con más detalle la actividad de los dispositivos de almacenamiento.

La diferencia es sencilla:

top puede decir qué está ocurriendo ahora.

Una secuencia de mediciones puede mostrar qué patrón está produciendo el problema.

Cuando la aplicación no explica el fallo, mirar el kernel

Hay situaciones donde el servicio solo informa de que algo ha fallado.

El kernel puede aportar la pieza que falta.

Por ejemplo:

journalctl -k -b

puede revelar problemas con discos, memoria, controladores o interfaces de red.

Si un proceso desaparece aparentemente sin explicación, también conviene buscar señales relacionadas con presión de memoria y el OOM killer.

Un fallo que parece originarse en una aplicación puede estar provocado realmente por el sistema operativo.

Los hábitos más importantes aparecen antes de pulsar Enter

Linux permite hacer muchísimo con una sola línea.

Eso es una ventaja y también un riesgo.

Por ejemplo:

find /backup -type f -mtime +30 -delete

elimina directamente todos los archivos que coincidan.

Antes puede probarse la selección sin borrar nada:

find /backup -type f -mtime +30 -print

Si el resultado es correcto, entonces se añade -delete.

Lo mismo ocurre con rsync.

Antes de ejecutar:

rsync -a --delete /source/ /destination/

resulta prudente probar:

rsync -a --delete --dry-run /source/ /destination/

--dry-run muestra qué ocurriría sin realizar realmente las modificaciones.

Este pequeño hábito puede evitar pérdidas importantes de datos.

Validar una configuración antes de reiniciar

Supongamos que se modifica nginx.

En lugar de editar y reiniciar directamente, puede probarse primero:

nginx -t

Solo después, si todo es correcto:

systemctl reload nginx

Esto introduce otra buena secuencia de trabajo:

editar
validar
comparar
recargar
comprobar

en lugar de:

editar
reiniciar
esperar

Además, siempre que un servicio soporte correctamente reload, puede ser preferible a un reinicio completo.

kill -9 debería ser el último recurso

Cuando un proceso parece bloqueado puede resultar tentador utilizar directamente:

kill -9 PID

Pero SIGKILL termina el proceso inmediatamente sin permitirle realizar tareas de limpieza.

Normalmente conviene empezar por:

kill PID

que envía SIGTERM.

Y antes de cualquiera de las dos opciones puede confirmarse qué proceso se está manipulando:

ps -fp PID

Incluso puede consultarse información adicional:

cat /proc/PID/status

Hay momentos en los que kill -9 es necesario.

El hábito consiste en no utilizar la intervención más agresiva como primera opción.

Automatizar bien es algo más que escribir un script

Muchos scripts funcionan perfectamente al ejecutarlos manualmente y fallan después en cron o systemd.

La causa suele estar en el entorno.

Una terminal interactiva puede disponer de un PATH, variables, claves SSH o un directorio de trabajo que no existen cuando se ejecuta automáticamente.

En lugar de:

python backup.py

puede utilizarse:

/usr/bin/python3 /opt/scripts/backup.py

También conviene definir explícitamente el entorno que necesita el script y no depender de aliases personales.

Comprobar si un comando ha funcionado

Bash utiliza códigos de salida.

Después de un comando puede consultarse:

echo $?

El valor 0 normalmente significa éxito.

En scripts suele ser mejor comprobar directamente la operación:

if rsync -a /data/ /backup/data/; then
    echo "Backup completed"
else
    echo "Backup failed" >&2
    exit 1
fi

Así el resultado forma parte de la propia lógica.

Una copia de seguridad no debe considerarse correcta simplemente porque el script llegó hasta el final.

set -e no arregla automáticamente todos los errores

Es frecuente encontrar:

set -e

para hacer que un script se detenga al producirse un fallo.

Puede ser útil, pero Bash tiene varias excepciones a su comportamiento.

Una configuración frecuente es:

set -Eeuo pipefail

pipefail resulta especialmente interesante en tuberías.

Por ejemplo:

grep "error" archivo-inexistente | sort

sin pipefail puede terminar devolviendo el resultado de sort, aunque grep haya fallado.

Aun así, ningún conjunto de opciones sustituye una gestión explícita de errores en automatizaciones importantes.

Automatizar las comprobaciones puede ser mejor que automatizar las reparaciones

No toda automatización tiene que corregir algo.

También puede limitarse a avisar.

Por ejemplo:

systemctl is-active --quiet nginx || echo "nginx is not active"

A partir de ahí pueden comprobarse automáticamente:

• espacio libre;
• copias de seguridad recientes;
• certificados próximos a caducar;
• mounts obligatorios;
• servicios fallidos;
• puertos en escucha;
• estado de RAID;
• sincronización horaria.

Reiniciar automáticamente un servicio cada vez que aparece un problema puede ocultar una incidencia durante meses.

Detectarla y registrar su estado permite investigar la causa.

Guardar una fotografía del sistema antes de tocarlo

Un script de diagnóstico puede reunir en segundos información básica:

date
hostname
uptime
free -h
df -h
lsblk
systemctl --failed
ss -lntp
journalctl -p err -b --no-pager

Y almacenarla:

/opt/tools/capture-state.sh > "/var/tmp/state-$(date +%Y%m%d-%H%M%S).log" 2>&1

Si después hay que reiniciar un servicio o incluso todo el servidor, todavía queda una fotografía del estado anterior.

En incidencias complejas puede ser extremadamente útil.

El hábito que no necesita terminal: documentar lo aprendido

Cada problema solucionado puede convertirse en conocimiento reutilizable.

Un registro sencillo debería guardar:

• qué ocurrió;
• cuándo empezó;
• qué había cambiado;
• qué logs se revisaron;
• qué comandos ayudaron;
• cuál fue la causa;
• cómo se solucionó;
• cómo podría detectarse antes la próxima vez.

No hace falta una plataforma especial.

Un repositorio Git privado con documentos Markdown puede convertirse con el tiempo en una pequeña base de conocimiento sobre los problemas reales de una infraestructura.

Y tiene una ventaja importante: evita que seis meses después alguien tenga que redescubrir exactamente la misma solución.

La experiencia de un buen administrador no está solo en su memoria.

También está en los procedimientos que ha ido dejando por escrito.

Linux premia más el método que la velocidad

Dos personas pueden conocer exactamente los mismos comandos.

Una trabaja así:

reiniciar
probar
cambiar algo
volver a probar

La otra:

observar
guardar evidencias
delimitar
formular una hipótesis
comprobarla
cambiar lo mínimo
verificar

La segunda no necesariamente conoce más Linux.

Trabaja con un método mejor.

Y esta forma de administrar sistemas sigue siendo útil incluso cuando detrás existen Prometheus, Grafana, OpenTelemetry, Kubernetes o sofisticadas plataformas de observabilidad.

Cuando algo falla, siempre llega un momento en el que hay que responder preguntas concretas: qué proceso existe, qué puerto escucha, qué cambió, qué filesystem está lleno o qué escribió el kernel antes de que todo empezara a fallar.

Los comandos ayudan a obtener esas respuestas.

Los buenos hábitos determinan si se hacen las preguntas correctas antes de modificar el sistema.

Preguntas frecuentes

¿Qué debería comprobarse primero cuando falla un servidor Linux?

Depende del problema, pero revisar systemctl status, journalctl, systemctl --failed, ss, df, free y findmnt permite obtener rápidamente una primera fotografía del estado del sistema.

¿Por qué no conviene reiniciar inmediatamente un servicio?

Porque el reinicio puede modificar el estado y añadir nuevos registros, dificultando descubrir qué provocó el fallo original. Primero conviene recoger evidencias.

¿Para qué sirve --dry-run?

Permite simular determinadas operaciones sin aplicar realmente sus cambios. Herramientas como rsync lo utilizan para mostrar qué archivos copiarían o eliminarían antes de ejecutar la operación real.

¿Es suficiente set -e para hacer seguros los scripts Bash?

No. Puede ayudar a detener scripts ante determinados errores, pero tiene excepciones. En automatizaciones importantes conviene comprobar explícitamente los resultados y comprender también opciones como pipefail.

Fuentes:

• Documentación oficial de systemd: systemctl, journalctl y systemd-analyze.
• GNU Bash Reference Manual.
• Proyecto util-linux: documentación de lsblk y findmnt.
• iproute2: documentación de ss.
• procps-ng y sysstat: herramientas de diagnóstico y rendimiento.