Servidor FiveM se Cae Solo: Cómo Mantenerlo Online 24/7 con Auto-Restart

¿Tu servidor FiveM se cae solo? Configura auto-restart, watchdog y monitoreo de RAM/CPU para mantenerlo online 24/7 sin intervención manual.

Que un servidor FiveM se caiga en pleno horario pico es uno de los problemas más frustrantes para quien mantiene una comunidad. El jugador se desconecta, pierde progreso, se queja en Discord, y tú descubres el crash horas después cuando alguien avisa. Sin auto-restart, cada caída se convierte en una intervención manual de madrugada.

Esta guía es para quien ya tiene un servidor FiveM corriendo en VPS Linux (Ubuntu o Debian) y quiere configurar una capa de auto-recuperación que mantenga el servicio online 24/7 — incluso si el FXServer crashea, vuelve solo en segundos. Vamos a cubrir el diagnóstico de la causa real, la configuración del watchdog con systemd, el monitoreo de RAM/CPU y el auto-restart programado para mitigar memory leak.

Tiempo estimado: 30-45 minutos para la implementación completa, incluyendo pruebas.

Requisitos previos

Antes de empezar, confirma que tienes acceso al servidor y las herramientas básicas instaladas.

Requisitos previos

Necesitas Ubuntu 22.04 LTS o Debian 12 con acceso root vía SSH, FXServer ya instalado y funcionando (cayéndose, pero funcionando) y txAdmin configurado. También se recomienda: mínimo 4 GB de RAM, 2 vCPUs y SSD.

Puerto por defecto FiveM 30120/udp + tcp
Puerto txAdmin 40120/tcp
Usuario service fivem (no root)
Directorio por defecto /home/fivem/server

Si todavía corres el FXServer dentro de tmux o screen, esta guía reemplaza ese setup por systemd — que es la forma correcta de mantener cualquier servicio de larga duración en Linux.

Diagnóstico: por qué se está cayendo

Antes de configurar auto-restart, necesitas saber qué está matando el proceso. Aplicar auto-restart encima de un problema no diagnosticado es tratar el síntoma e ignorar la enfermedad.

01

Verifica si fue un OOM kill (falta de memoria):

sudo dmesg -T | grep -i "killed process"
sudo journalctl -k --since "24 hours ago" | grep -i oom

Si aparece una línea tipo Killed process 12345 (FXServer) total-vm:8GB, el kernel lo mató por falta de RAM. Eso indica memory leak en algún resource o que la VPS está infradimensionada.

02

Verifica si fue crash interno del FXServer:

tail -n 500 /home/fivem/server/server.log | grep -iE "error|exception|crash"

Busca stack trace o líneas con [script:resource_name] ERROR. Resources Lua con loop infinito o excepciones no tratadas tumban todo el servidor.

03

Revisa saturación de red (posible DDoS):

sudo apt install -y vnstat
vnstat -l -i eth0

Si el tráfico de entrada (rx) está en cientos de Mbps con pocos jugadores conectados, es flood. Anota el pico para comparar después.

Crashes sin patrón son memory leak

Si el servidor se cae siempre cerca del mismo uptime (por ejemplo, cada 8-10h), casi con seguridad es un memory leak gradual. Monitorea con htop durante una sesión completa para ver la RAM del proceso FXServer crecer linealmente hasta reventar.

Configurando systemd como watchdog

Systemd es el init system por defecto de Linux y tiene soporte nativo para reiniciar servicios que crashean. Vamos a crear una service unit dedicada para el FXServer.

01

Crea un usuario dedicado para el servidor (si todavía corre como root, esto es obligatorio por seguridad):

sudo useradd -m -s /bin/bash fivem
sudo chown -R fivem:fivem /home/fivem/server

Correr servicios expuestos a internet como root es un vector de compromiso total si se descubre una RCE en el FXServer.

02

Crea el archivo de service unit:

sudo nano /etc/systemd/system/fivem.service

Pega el contenido de abajo, ajustando los paths según tu instalación:

[Unit]
Description=FiveM FXServer
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=fivem
Group=fivem
WorkingDirectory=/home/fivem/server
ExecStart=/home/fivem/server/run.sh +exec server.cfg
Restart=always
RestartSec=10
StartLimitBurst=5
StartLimitIntervalSec=300
StandardOutput=append:/home/fivem/server/server.log
StandardError=append:/home/fivem/server/server.error.log
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Las directivas críticas: Restart=always reinicia ante cualquier salida (crash o exit normal), RestartSec=10 espera 10 segundos entre intentos (da tiempo a que el socket UDP se libere) y StartLimitBurst=5 evita un loop infinito si el servidor está realmente roto.

03

Activa e inicia el service:

sudo systemctl daemon-reload
sudo systemctl enable fivem.service
sudo systemctl start fivem.service
sudo systemctl status fivem.service

La salida debe mostrar active (running) en verde. Si aparece failed, ejecuta sudo journalctl -u fivem.service -n 50 para ver el error.

Detén primero el txAdmin/tmux anterior

Si tenías el FXServer corriendo en tmux o vía txAdmin standalone, mata esos procesos antes de iniciar systemd. Dos procesos intentando bindear al mismo puerto UDP causan crash en loop y pueden corromper el save state de los resources.

Auto-restart programado para mitigar memory leak

Aun con la causa raíz corregida, es buena práctica programar un reinicio diario para liberar memoria y evitar degradación. Hazlo en el horario de menor actividad.

01

Crea un timer systemd para reinicio diario a las 6 de la mañana:

sudo nano /etc/systemd/system/fivem-restart.timer
[Unit]
Description=Restart FiveM daily at 6am

[Timer]
OnCalendar=*-*-* 06:00:00
Persistent=true

[Install]
WantedBy=timers.target

Y el service que el timer dispara:

sudo nano /etc/systemd/system/fivem-restart.service
[Unit]
Description=Restart FiveM service

[Service]
Type=oneshot
ExecStart=/bin/systemctl restart fivem.service
02

Activa el timer:

sudo systemctl daemon-reload
sudo systemctl enable fivem-restart.timer
sudo systemctl start fivem-restart.timer
sudo systemctl list-timers fivem-restart.timer

La salida debe mostrar la próxima programación. Puedes ajustar el horario a otro momento — elige siempre cuando el servidor tenga menos jugadores online.

Avisa a los jugadores antes del restart

Configura un resource que haga broadcast in-game 5 y 1 minuto antes del horario de restart. Un reinicio sorpresa frustra a los jugadores y genera quejas. Resources como vMenu o txAdmin scheduled restarts lo hacen de forma nativa.

Monitoreo continuo de RAM y CPU

El auto-restart solo es eficaz si sabes cuándo está ocurriendo demasiado. Un monitoreo básico te avisa de degradación antes de que se vuelva problema.

01

Instala htop y vnstat para observación en tiempo real:

sudo apt install -y htop vnstat
sudo systemctl enable --now vnstat

htop muestra proceso a proceso. Filtra con F4 y escribe FXServer para ver solo lo que importa.

02

Crea un script de alerta simple que revise la RAM del FXServer cada 5 minutos:

sudo nano /usr/local/bin/fivem-mem-check.sh
#!/bin/bash
THRESHOLD=85
MEM_PERCENT=$(ps -o %mem= -C FXServer | head -n1 | tr -d ' ')
MEM_INT=${MEM_PERCENT%.*}

if [ "$MEM_INT" -gt "$THRESHOLD" ]; then
  echo "$(date): FXServer usando ${MEM_PERCENT}% RAM" >> /var/log/fivem-mem.log
  # Opcional: enviar a webhook de Discord
  # curl -H "Content-Type: application/json" -d "{\"content\":\"FiveM RAM alta: ${MEM_PERCENT}%\"}" $DISCORD_WEBHOOK
fi

Hazlo ejecutable y prográmalo en cron:

sudo chmod +x /usr/local/bin/fivem-mem-check.sh
echo "*/5 * * * * root /usr/local/bin/fivem-mem-check.sh" | sudo tee /etc/cron.d/fivem-mem

Verificación

Confirma que toda la stack está funcionando antes de considerar el setup completo.

01

Fuerza un crash simulado para ver si el auto-restart funciona:

sudo pkill -9 FXServer
sleep 15
sudo systemctl status fivem.service

Después de 10-15 segundos, el status debe mostrar active (running) nuevamente, con uptime corto. Si aparece failed o inactive, revisa el service unit.

02

Mira los últimos restarts en el log de systemd:

sudo journalctl -u fivem.service --since "1 hour ago" | grep -E "Started|Stopped"

Cada par Started/Stopped representa un ciclo de restart. Una frecuencia alta indica que la causa raíz no se resolvió.

Resolución de problemas

El servidor reinicia en loop infinito

Si systemd se queda reiniciando el servicio cada pocos segundos sin estabilizarse, generalmente es problema de configuración en server.cfg o un resource roto. Detén el auto-restart temporalmente con sudo systemctl stop fivem.service, ejecuta run.sh manualmente como usuario fivem y lee el output directo en la terminal. El error aparece al instante.

Puerto ya en uso después del restart

El socket UDP puede quedarse en estado TIME_WAIT durante algunos segundos. Aumenta RestartSec en el service unit de 10 a 20-30 segundos. Si el problema persiste, fuerza la liberación con sudo fuser -k 30120/udp antes de reiniciar.

txAdmin no detecta el servidor reiniciado por systemd

Cuando migras de txAdmin standalone a systemd, txAdmin pierde el control del proceso. Solución: corre txAdmin como parte del mismo service unit (pasando +set txAdminPort 40120 en ExecStart) o acepta que txAdmin queda solo como dashboard de visualización — el restart real viene de systemd.

Próximos pasos

Con el auto-restart funcionando, vale la pena evolucionar el setup:

  • Configura un backup automático de la base de datos (MySQL o MariaDB) con mysqldump en cron diario
  • Implementa monitoreo externo con Uptime Kuma o similar para alertarte cuando el servidor esté realmente offline
  • Optimiza los resources problemáticos — usa resmon in-game para identificar cuáles consumen más CPU/RAM
  • Considera separar la base de datos en un servidor propio si pasas de 64 slots
  • Configura firewall (ufw o nftables) limitando los puertos expuestos y protegiendo contra escaneo automatizado

Si tu servidor FiveM está crasheando por sobrecarga de hardware y no por bug de resource, vale comparar lo que tu VPS actual entrega vs un hospedaje optimizado para juegos — vCPU dedicada y protección DDoS evitan buena parte de las categorías de crash que cubrimos aquí.

Preguntas frecuentes

¿Por qué mi FXServer crashea sin mensaje de error?

En la mayoría de los casos es OOM (out-of-memory) — el kernel de Linux mata el proceso silenciosamente cuando la RAM se agota. Verifícalo con `dmesg | grep -i 'killed process'` o `journalctl -k | grep -i oom`. Otras causas comunes: un script Lua con loop infinito bloqueando el hilo principal y timeout de heartbeat con el CnL (Cfx.re).

¿Cuál es la diferencia entre el restart de txAdmin y el de systemd?

txAdmin reinicia solo el proceso FXServer dentro del mismo runtime — es rápido, pero si el problema es un memory leak persistente, la fuga continúa. Systemd mata todo el proceso y sus hijos, libera la memoria completamente e inicia desde cero. Para crashes recurrentes, systemd es más robusto.

¿Cuántos jugadores aguanta un servidor FiveM antes de caerse?

Depende más de los scripts que del hardware. Un servidor de 32 slots con pocos resources corre en 4 GB de RAM sin problemas. Con 64+ slots y scripts pesados (ESX/QBCore + custom), cuenta 8-16 GB. El cuello de botella casi siempre es un hilo de CPU saturado por un script mal escrito, no falta de RAM total.

¿El auto-restart resuelve un memory leak permanente?

Trata el síntoma, no la causa. Un reinicio programado cada 6-12h enmascara el leak y mantiene el servidor online, pero cada reinicio expulsa a todos los jugadores. Lo ideal es identificar el resource culpable con `resmon` in-game y corregirlo o reemplazarlo. El auto-restart es solución temporal mientras investigas.

txAdmin ya tiene monitor — ¿también necesito systemd?

Sí. txAdmin monitorea el FXServer, pero si el propio txAdmin se cuelga o el proceso Node.js muere, nadie lo reinicia. Systemd queda una capa por encima, vigilando a txAdmin. Es defensa en profundidad: txAdmin cuida el juego, systemd cuida a txAdmin.

¿Cómo saber si el crash es por DDoS o problema interno?

Mira el log del FXServer en el momento de la caída. Un crash interno deja stack trace o mensaje de excepción. Un DDoS aparece como tx/rx de red saturado (`vnstat -l`) sin error en el log del FXServer — el proceso simplemente deja de responder porque el ancho de banda está consumido. Una hospedaje con protección DDoS resuelve la segunda categoría.

Temas:
Próximos pasos VPS, dedicado o panel gestionado para FiveM, SAMP, MTA, Tibia y más.Aloja tu servidor de juegos con Hostini →
¿Te resultó útil este tutorial?
Hablar por WhatsApp