Ábrela cuando un servidor Linux falla o va lento y necesitas el comando exacto sin buscarlo. Si no sabes por dónde empezar, ve a los escenarios del final: cada uno da el orden en que mirar.
1. Logs con journalctl
Sigue los logs de un servicio en tiempo real.
journalctl -u nginx.service -fMuestra los logs a partir de un momento concreto.
journalctl --since "2 hours ago"Filtra solo los errores de un servicio en el arranque actual.
journalctl -u mi-app.service -p 3 -xbMuestra los mensajes del kernel, útiles ante fallos de hardware o de memoria (OOM).
journalctl -k2. Logs en ficheros
Muestra las últimas 50 líneas de un log y sigue escribiendo las nuevas.
tail -n 50 -f /var/log/syslogBusca un error y enseña 2 líneas de contexto antes y después.
grep -C 2 "Exception" /var/log/mi-app/error.logBusca una palabra sin distinguir mayúsculas de minúsculas.
grep -i "error" /var/log/auth.logLista las 10 IP que más peticiones hacen en el log de acceso.
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -103. Tareas programadas con crontab
Edita las tareas programadas del usuario actual.
crontab -eLista las tareas programadas del usuario actual.
crontab -lEdita el crontab de otro usuario (requiere sudo).
sudo crontab -u root -e4. Sintaxis de cron
El formato de cada línea es minuto hora día-del-mes mes día-de-la-semana comando.
Ejecuta un script todos los días a las 02:30.
30 2 * * * /ruta/al/script-backup.shEjecuta un script cada 15 minutos.
*/15 * * * * /ruta/al/script.shEjecuta un script cada lunes a las 08:00 y guarda la salida y los errores en un log.
0 8 * * 1 /ruta/al/mantenimiento.sh >> /var/log/mantenimiento.log 2>&15. Recursos del sistema
Muestra los procesos y su consumo de CPU y memoria en tiempo real (si no está instalado, usa top).
htopMuestra el uso de memoria RAM en megas.
free -mMuestra el espacio libre en disco en un formato legible.
df -h6. Procesos y puertos
Busca el PID de un proceso por su nombre.
ps aux | grep nodeFuerza el cierre de un proceso por su PID.
kill -9 12345Fuerza el cierre de todos los procesos con un nombre concreto.
killall -9 php-fpmMuestra qué proceso escucha en un puerto.
ss -tulpn | grep 8080Alternativa para ver qué proceso tiene abierto un puerto.
lsof -i :80807. Compresión y copias
Comprime un directorio en un fichero .tar.gz.
tar -czvf backup-app.tar.gz /var/www/mi-app/Descomprime un .tar.gz en el directorio actual.
tar -xzvf archivo.tar.gzSincroniza un directorio con un servidor remoto copiando solo lo que ha cambiado.
rsync -avz /directorio/local/ usuario@servidor:/directorio/remoto/Copia un fichero a un servidor remoto por SSH.
scp archivo.zip usuario@servidor:/ruta/destino/8. Permisos y propietarios
Cambia el propietario y el grupo de un directorio de forma recursiva.
sudo chown -R www-data:www-data /var/www/mi-app/Da todos los permisos al propietario y lectura y ejecución al resto, de forma recursiva.
sudo chmod -R 755 /var/www/mi-app/Da permiso de ejecución a un script.
chmod +x script.sh9. Escenario: el disco está lleno
situaciónLa aplicación empieza a fallar al escribir y los logs dicen «No space left on device».
qué hay que entender
Un disco se llena de dos maneras: por espacio o por inodos, que es el número máximo de ficheros. Además, un fichero borrado que un proceso tiene abierto sigue ocupando hasta que el proceso lo suelta. Por eso un rm de un log enorme a veces no libera nada.
Los culpables habituales son los logs, el journal, las cachés de paquetes y las imágenes de Docker.
pasos, en orden
-
Mira qué sistema de ficheros está lleno y cuánto.
df -h -
Descarta que el problema sean los inodos: si
IUse%está al 100 %, sobran ficheros, no gigas.df -i -
Busca qué carpeta ocupa más, sin salir de esa partición (
-x).sudo du -xh / 2>/dev/null | sort -h | tail -n 15 -
Lista los ficheros borrados que siguen abiertos; reinicia el proceso que los tiene para liberar el espacio.
sudo lsof +L1 -
Recorta el journal de systemd a un tamaño fijo.
sudo journalctl --vacuum-size=200M -
Vacía un log que la aplicación tiene abierto en vez de borrarlo, para que el espacio se libere al momento.
sudo truncate -s 0 /var/log/mi-app/app.log
cómo sé que está resuelto
df -h vuelve a dejar margen (por debajo del 80 %) y la aplicación escribe sin errores. Para que no se repita: rotación de logs con logrotate y una alarma de disco, que en EC2 necesita el agente de CloudWatch.
si no funciona
Si du no explica lo que dice df y lsof +L1 no muestra nada, mira dos cosas. Puede haber datos escritos debajo de un punto de montaje, antes de montarlo. Y en ext4, por defecto el 5 % queda reservado para root. Si hay Docker, docker system df dice cuánto ocupan imágenes y volúmenes.
en una entrevista«Un servidor se ha quedado sin disco. ¿Qué haces?»
- Contener: libero algo seguro (journal, logs rotados) para que el servicio vuelva a funcionar.
- Diagnosticar:
df -hydf -ipara saber qué se ha llenado,du -xpara encontrar qué, ylsof +L1por si hay ficheros borrados aún abiertos. - Corregir la causa: rotación y retención de logs, o limpiar lo que crece sin control.
- Prevenir: una alarma antes de llegar al 100 %, por ejemplo al 80 %.
La trampa que conviene nombrar: borrar un log abierto no libera espacio hasta reiniciar el proceso.
10. Escenario: un servicio no arranca
situaciónTras un despliegue o un reinicio, el servicio aparece como «failed» y la aplicación no responde.
qué hay que entender
systemd arranca el proceso de la unidad. Si sale con error, la marca como failed y, según su Restart=, lo vuelve a intentar.
El motivo casi siempre está en las últimas líneas del log de esa unidad. Las causas típicas son una configuración inválida, un puerto ocupado, permisos o una variable de entorno que falta.
pasos, en orden
-
Mira el estado y las últimas líneas del log en una sola vista.
systemctl status mi-app.service -
Lee el log completo de la unidad desde el último arranque del sistema.
journalctl -u mi-app.service -b --no-pager | tail -n 50 -
Comprueba si otro proceso ya ocupa el puerto que necesita el servicio.
sudo ss -tlnp | grep ':8080' -
Revisa qué ejecuta exactamente la unidad, con qué usuario y con qué entorno.
systemctl cat mi-app.service -
Tras corregir, recarga las unidades (solo si cambiaste el fichero) y arranca de nuevo.
sudo systemctl daemon-reload && sudo systemctl restart mi-app.service
cómo sé que está resuelto
systemctl is-active mi-app.service devuelve active y la aplicación responde, por ejemplo con curl -I http://localhost:8080/.
si no funciona
Ejecuta a mano el comando de ExecStart con el mismo usuario (sudo -u <usuario> …) para ver el error en directo. Si arranca y muere al rato, mira journalctl -k: el kernel puede estar matándolo por falta de memoria (OOM). Si systemd dice «start request repeated too quickly», limpia el contador con systemctl reset-failed mi-app.service antes de reintentar.
en una entrevista«Has desplegado y el servicio no levanta. ¿Por dónde empiezas?»
- Estado y log de la unidad:
systemctl statusyjournalctl -u, porque el error casi siempre está ahí. - Qué ha cambiado: si viene de un despliegue, comparo con la versión anterior (configuración, variables, dependencias).
- Causas típicas, en orden: configuración, puerto ocupado, permisos, entorno.
- Reproducir a mano el comando de arranque para ver el error sin intermediarios.
- Si tarda, vuelvo atrás a la versión anterior y lo investigo sin el servicio caído.
11. Escenario: el servidor va lento
situaciónLa aplicación responde despacio y no hay ningún error claro en los logs.
qué hay que entender
«Lento» puede venir de cuatro recursos: CPU, memoria, disco o red. La carga media (load average) cuenta los procesos que esperan CPU y, en Linux, también los bloqueados esperando al disco. Por eso se compara con el número de núcleos, no con un valor fijo.
En memoria, que haya poca libre es normal, porque Linux la usa de caché. Lo que importa es la columna available y si se está usando swap.
pasos, en orden
-
Compara la carga media con el número de núcleos: si la supera de forma sostenida, hay cola.
uptime && nproc -
Mira qué procesos consumen más CPU.
ps aux --sort=-%cpu | head -n 10 -
Revisa la memoria disponible y el uso de swap.
free -h -
Mira cinco muestras de un segundo:
waalto es espera de disco ysi/sodistintos de cero, swap en uso.vmstat 1 5 -
Comprueba si el kernel ha matado procesos por falta de memoria.
sudo journalctl -k | grep -i 'out of memory'
cómo sé que está resuelto
La carga vuelve por debajo del número de núcleos, wa queda cerca de 0 y la aplicación responde en su tiempo normal. Antes de tocar nada, guarda la salida de estos comandos: es la evidencia para explicar qué pasó.
si no funciona
Si nada destaca, la lentitud puede estar fuera del servidor: la base de datos, la red o un servicio externo. En instancias de tipo t de AWS, mira también el saldo de créditos de CPU. Si se agota, la instancia baja a su rendimiento base aunque top no muestre nada raro.
en una entrevista«El servidor va lento. ¿Cómo lo diagnosticas?»
- Recurso por recurso (CPU, memoria, disco, red), mirando para cada uno cuánto se usa, si hay cola y si hay errores.
- Empiezo por la carga frente a los núcleos, que me dice si hay cola, y sigo por el proceso que más consume.
- Separo memoria real de caché:
available, nofree, y si hay swap. - No reinicio sin capturar antes la salida de los comandos: reiniciar lo arregla un rato y borra la evidencia.
- Si el servidor está sano, miro fuera: base de datos, red, dependencias o créditos de CPU.
12. Escenario: no puedo entrar por SSH
situaciónAl conectar sale «Connection timed out», «Connection refused» o «Permission denied (publickey)».
qué hay que entender
Cada mensaje apunta a una capa distinta. Timed out es red: el paquete no llega (firewall, security group, IP o ruta). Refused es que llega, pero nada escucha en el puerto, normalmente porque sshd está caído. Permission denied es que llega y sshd responde, pero rechaza la autenticación: la clave, el usuario o los permisos de ~/.ssh.
Leer bien el mensaje ahorra la mitad del diagnóstico.
pasos, en orden
-
Conecta en modo detallado para ver en qué punto se para.
ssh -vvv usuario@servidor -
Comprueba desde tu máquina si el puerto 22 responde.
nc -vz servidor 22 -
Si la clave es rechazada, revisa sus permisos en tu equipo: ssh ignora una clave privada que otros pueden leer.
chmod 600 ~/.ssh/id_ed25519 -
Desde un acceso alternativo (consola del proveedor o gestor de sesiones), mira si el servicio SSH está en marcha. En Debian y Ubuntu se llama
ssh; en RHEL,sshd.sudo systemctl status ssh -
Lee en el servidor por qué rechazó el intento.
sudo journalctl -u ssh --since "15 min ago" -
Corrige los permisos de
~/.sshdel usuario en el servidor, otra causa típica de «Permission denied».chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
cómo sé que está resuelto
ssh usuario@servidor entra sin pedir nada raro. Para comprobarlo desde un script, ssh -o BatchMode=yes usuario@servidor true devuelve 0.
si no funciona
Si es un timeout, mira las reglas de entrada: security group, ACL de red y firewall del sistema (sudo ufw status). En la nube, la IP pública puede haber cambiado al parar y arrancar la instancia. Si entras pero la sesión se cierra al instante, revisa el disco: un disco lleno también impide iniciar sesión (escenario 9). Comprueba también el usuario por defecto de la imagen, por ejemplo ec2-user o ubuntu.
en una entrevista«No puedes entrar por SSH a un servidor. ¿Qué haces?»
- Leo el mensaje exacto y lo clasifico: timeout es red, refused es el servicio y denied es la autenticación.
- Red: puerto accesible desde mi IP, reglas de entrada y IP actual de la máquina.
- Servicio: si
sshdestá en marcha, desde un acceso alternativo. - Autenticación: usuario, clave y permisos de
~/.ssh, y el log del servidor para ver el motivo. - Sin depender del puerto 22: en AWS, Session Manager da acceso sin abrirlo.
Lo que no haría: abrir el puerto 22 a todo internet «para probar».
13. Relacionado
- Alarmas de CloudWatch para EC2, probadas con carga real
- Laravel en producción: colas, Supervisor y logs
Ningún bloque coincide con el filtro.