VPSARG10 % de descuento todos los meses, ya aplicado en los precios10 % OFF todos los meses
ESEN
Ver planes
ESEN
Acceso clientes Ver planes

Qué hacer cuando un servicio se cae: estado, logs y reinicio

· 6 min de lectura · por el equipo técnico de VPS Argentina

Ante un servicio caído el orden es siempre el mismo: systemctl status para ver qué dice, journalctl -u servicio -n 50 para leer el error real, y recién después systemctl restart. Reiniciar primero borra la evidencia y el problema vuelve. Las tres causas que explican casi todo son la memoria agotada, el disco lleno y un archivo de configuración con un error tras una edición. En los VPS supervisados, el agente de IA reinicia los servicios caídos y deja el registro.

El orden correcto

  1. Mirá el estado: systemctl status nginx (o mariadb, php-fpm, lo que sea).
  2. Leé el log del servicio: journalctl -u nginx -n 50 --no-pager.
  3. Si editaste la configuración, probala antes de reiniciar: nginx -t, apachectl configtest, sshd -t.
  4. Reiniciá: systemctl restart nginx.
  5. Comprobá que quedó arriba y que arranca solo al reiniciar el servidor: systemctl is-enabled nginx.

Las tres causas de siempre

CausaCómo se veCómo se comprueba
Memoria agotadaEl servicio muere solo, sin que nadie lo toque, y en el log del sistema aparece el asesino de procesos.free -h y journalctl -k | grep -i oom
Disco llenoTodo empieza a fallar a la vez: la base no escribe, el sitio da error, el correo rebota.df -h y du -sh /var/log/*
Configuración rotaEl servicio no arranca desde la última edición.La prueba de configuración de cada servicio

Si el problema es memoria y se repite, el servidor quedó chico: ampliar la RAM del VPS se hace sin migrar ni reinstalar.

Ver todo de un vistazo

systemctl --failed
df -h
free -h
uptime

Esos cuatro comandos, en ese orden, resuelven el 80% de los diagnósticos: qué falló, si hay disco, si hay memoria y desde cuándo está así.

Reiniciar el servidor entero

Es el último recurso, no el primero: borra el estado que necesitás para entender qué pasó. Cuando haga falta:

reboot

Si el servidor no responde ni por SSH ni por consola, en el panel está el apagado forzado y el reinicio, que equivale a cortarle la luz. Se usa cuando no queda otra, porque una base de datos escribiendo en ese momento puede quedar inconsistente.

Dónde están los logs

  • Del sistema y de cualquier servicio: journalctl -u servicio.
  • Del arranque anterior, útil después de una caída: journalctl -b -1 -p err.
  • De Apache o Nginx: en /var/log/apache2/, /var/log/httpd/ o /var/log/nginx/.
  • De un sitio con DirectAdmin: dentro de la carpeta logs de la cuenta.

Preguntas frecuentes

¿Reinicio el servicio o el servidor?

Siempre primero el servicio. Reiniciar el servidor entero corta todo lo demás y borra la información que explica la caída.

El servicio arranca y se cae a los segundos

Casi siempre es configuración o memoria. journalctl -u servicio -n 50 muestra el error exacto en las últimas líneas antes de la caída.

¿Cómo hago que arranque solo con el servidor?

Con systemctl enable servicio. Comprobalo con systemctl is-enabled servicio: si dice disabled, después de un reinicio no vuelve.

Se llenó el disco de logs

Limitá el tamaño del diario con journalctl --vacuum-size=200M y revisá que logrotate esté funcionando. Un sitio que escribe errores en bucle llena cualquier disco.

¿El agente de IA me avisa?

Actúa y registra. Lo que se ve desde afuera es la página de estado del servicio y, ante incidentes con impacto, el aviso por correo a los clientes afectados.

Seguí leyendo