Cómo hacer que FiveM inicie automáticamente al encender la VPS
Configura el servidor FiveM para que arranque solo tras un reinicio de la VPS Linux usando systemd, con reinicio automático en caso de fallo y logs centralizados.
Un servidor FiveM en producción tiene una regla simple: tiene que estar en línea cuando el jugador entra. La VPS se reinicia por una actualización de kernel, un corte de energía en el datacenter, un mantenimiento programado o un fallo del propio proceso FXServer — y cualquiera de esos eventos tumba el servidor si depende de que tú reabras manualmente tmux y ejecutes run.sh.
Este tutorial configura el servidor FiveM en una VPS Linux para que arranque solo en el boot del sistema, se reinicie automáticamente ante un fallo y quede monitoreado vía systemd como cualquier servicio de producción. La persona objetivo es el owner que ya tiene el servidor instalado, sabe ejecutar run.sh manualmente y quiere eliminar la dependencia de una sesión SSH activa.
Tiempo estimado: 15 a 20 minutos. Vale para cualquier Linux con systemd (Ubuntu 22.04+, Debian 12+, AlmaLinux 9+).
Prerrequisitos
Necesitas una VPS Linux con FXServer ya instalado y funcionando manualmente, acceso sudo (o root), el puerto 30120 abierto en el firewall y conocimiento básico de un editor de texto (nano o vim). Si aún no instalaste FiveM, hazlo antes — este tutorial asume que bash run.sh levanta el servidor sin errores.
Identifica los datos de tu setup actual antes de continuar — los vas a necesitar al escribir el service unit:
/home/fivem/server /home/fivem/server-data fivem 30120 UDP/TCP Las rutas de arriba son una convención — ajústalas para reflejar tu estructura real. Si instalaste todo en /root/fivem, cámbialas por tus rutas en cada comando de este tutorial.
Crear un usuario dedicado para el servidor
Ejecutar FiveM como root es un vector innecesario de riesgo. Si ya tienes un usuario separado, omite esta sección.
Crea el usuario del sistema sin shell interactivo (no necesitas iniciar sesión directamente con él):
sudo adduser --system --group --home /home/fivem --shell /bin/bash fivemEl flag --system crea un UID bajo (por debajo de 1000), estándar para cuentas de servicio. --group crea un grupo con el mismo nombre.
Mueve los archivos del FXServer dentro del home del nuevo usuario (si aún no están allí) y corrige el propietario:
sudo chown -R fivem:fivem /home/fivemEsto garantiza que el proceso ejecutándose como fivem pueda leer los recursos, escribir logs y grabar caché.
Confirma que el usuario puede ejecutar el servidor manualmente. Haz sudo -u fivem -i para cambiar a él y prueba:
cd /home/fivem/server-data
bash ../server/run.sh +exec server.cfgSi arranca sin errores, ciérralo con Ctrl+C. El service unit de systemd va a ejecutar exactamente ese comando — solo que sin terminal anclada.
Crear el service unit de systemd
El service unit es un archivo de texto que describe a systemd cómo iniciar, parar y monitorear tu servidor. Vive en /etc/systemd/system/ con extensión .service.
Crea el archivo del servicio:
sudo nano /etc/systemd/system/fivem.servicePega la configuración de abajo, ajustando las rutas para reflejar tu instalación:
[Unit]
Description=FiveM Server (FXServer)
After=network-online.target mysql.service
Wants=network-online.target
Requires=mysql.service
[Service]
Type=simple
User=fivem
Group=fivem
WorkingDirectory=/home/fivem/server-data
ExecStart=/home/fivem/server/run.sh +exec server.cfg
Restart=on-failure
RestartSec=10
StartLimitBurst=5
StartLimitIntervalSec=300
StandardOutput=journal
StandardError=journal
SyslogIdentifier=fivem
# Endurecimiento opcional pero recomendado
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only
ReadWritePaths=/home/fivem
[Install]
WantedBy=multi-user.targetCada bloque tiene un papel específico:
After=yRequires=mysql.servicegarantizan que la base de datos esté lista antes de que el servidor arranque. Si usas MariaDB, cambia pormariadb.service. Si no tienes base de datos, elimina esas dos líneas.Restart=on-failurereinicia ante un fallo pero no ante una salida limpia (Ctrl+C /systemctl stop).StartLimitBurst=5yStartLimitIntervalSec=300impiden el bucle infinito de reinicio consumiendo CPU.- El bloque de endurecimiento aísla el proceso del resto del sistema — si se carga un recurso explotable, el daño queda contenido.
La directiva ProtectHome=read-only impide que el proceso escriba en cualquier /home. Si instalaste FiveM fuera de /home (ej: /opt/fivem o /root/fivem), ajusta ReadWritePaths= para apuntar a esa carpeta — de lo contrario el servidor no puede grabar caché ni logs y rompe silenciosamente.
Guarda el archivo (Ctrl+O, Enter, Ctrl+X en nano) y recarga systemd para que vea el nuevo unit:
sudo systemctl daemon-reloadSin ese comando, cualquier cambio en archivos .service es ignorado hasta el próximo reinicio.
Habilitar e iniciar el servicio
enable hace que el servicio arranque automáticamente en cada boot. start lo inicia ahora. Los dos están separados a propósito — puedes querer uno sin el otro.
Habilita el arranque automático:
sudo systemctl enable fivem.serviceLa salida muestra Created symlink /etc/systemd/system/multi-user.target.wants/fivem.service. Ese symlink es lo que hace que systemd cargue el servicio en cada inicialización.
Inicia el servicio ahora:
sudo systemctl start fivem.serviceEl comando retorna de inmediato — el proceso arranca en segundo plano. No confundas silencio con éxito, verifica el estado en la siguiente sección.
Verificar que está funcionando
Comprueba el estado del servicio:
sudo systemctl status fivem.serviceDeberías ver Active: active (running) en verde, con PID, tiempo de uptime y las últimas líneas de log. Si aparece failed, ve directo a los logs detallados.
Sigue los logs en tiempo real:
sudo journalctl -u fivem.service -f-u filtra por el unit, -f sigue en tiempo real (Ctrl+C para salir). Deberías ver los mensajes típicos de boot del FXServer: Server started on port 30120, carga de recursos, etc.
Prueba el reinicio automático provocando una caída. Mata el proceso manualmente:
sudo pkill -f FXServerEspera 10 segundos (el RestartSec=10 del unit) y ejecuta systemctl status fivem.service de nuevo. El PID debe ser distinto — systemd reinició solo. Los logs van a mostrar Stopped, Start request repeated too quickly (si es el caso) o un nuevo Started.
Por último, la prueba definitiva: reinicia la VPS.
sudo rebootEspera 1-2 minutos, reconéctate vía SSH y ejecuta systemctl status fivem.service. Si está active (running), tu configuración está completa — el servidor ahora arranca solo en cualquier reinicio futuro.
Resolución de problemas
El servicio se queda en “activating” y nunca llega a “active”
El FXServer tarda algunos segundos en inicializar recursos. Si el servicio queda atascado en activating (auto-restart), generalmente es un fallo en el boot. Mira los logs completos del último ciclo:
sudo journalctl -u fivem.service -n 100 --no-pagerErrores comunes: server.cfg con sintaxis errónea, recurso faltando en resources/, puerto 30120 ya en uso por otro proceso, o MySQL todavía no está listo. Si es el último caso, confirma con systemctl status mysql que la base de datos está active.
El servidor arranca pero nadie puede conectarse
Verifica si el puerto está realmente escuchando:
sudo ss -tulpn | grep 30120Debe aparecer una línea con users:(("FXServer",pid=...)). Si aparece pero la conexión externa falla, el problema es el firewall — confirma las reglas de UDP+TCP en el puerto 30120 con sudo ufw status o sudo iptables -L -n.
Logs muy verbosos llenando el disco
Por defecto, systemd-journal crece sin límite. Edita /etc/systemd/journald.conf y descomenta SystemMaxUse=500M y MaxRetentionSec=2week. Aplica con sudo systemctl restart systemd-journald. Esto mantiene historial suficiente para debug sin reventar el disco.
El servidor se reinicia en bucle y satura la CPU
El StartLimitBurst=5 ya protege contra esto, pero si removiste esa línea por algún motivo, actívala de nuevo. Para parar el bucle de inmediato sin editar el archivo:
sudo systemctl stop fivem.service
sudo systemctl reset-failed fivem.serviceLuego investiga el motivo del fallo en los logs antes de rehabilitar.
Próximos pasos
Con el servidor arrancando solo, vale la pena reforzar el setup con:
- txAdmin como wrapper: configurar el
ExecStartpara iniciar txAdmin en lugar del FXServer directo. Ganas un panel web para reinicio programado, gestión de recursos y protección extra contra fallos específicos del FXServer. - Backup automático de server-data: configurar
cronu otro timer de systemd para exportar la carpetaresources/y la base MySQL a un almacenamiento externo diariamente. - Monitoreo de uptime: integrar con Uptime Kuma o un healthcheck externo apuntando a
http://tu-ip:30120/info.json— recibes alerta cuando el servidor se cae incluso antes de que los jugadores reclamen. - Límites de recurso por systemd: añadir
MemoryMax=4GyCPUQuota=200%al unit para impedir que una fuga de memoria tumbe la VPS entera.
Si estás poniendo el servidor en producción, una VPS Hostini ya viene con baja latencia para los jugadores de LATAM y protección DDoS — combinada con el auto-reinicio de este tutorial, tu uptime queda en manos de la infraestructura y no de tu disponibilidad para ejecutar bash run.sh.
Preguntas frecuentes
¿Por qué usar systemd en lugar de tmux con cron @reboot?
systemd ofrece reinicio automático en caso de fallo, logs centralizados vía journalctl, dependencias de arranque (espera a que MySQL/Postgres suban antes), límites de recursos y watchdog. tmux + cron @reboot solo levanta el proceso una vez — si se cae a mitad de la madrugada, nadie lo reinicia. Para producción real es systemd; tmux sirve para desarrollo.
¿El servidor FiveM debe ejecutarse como root?
No, y no debería. Crea un usuario dedicado (`adduser fivem`), coloca los archivos del servidor en su home y configura el service unit con `User=fivem`. Funciona en puertos altos (30120 UDP/TCP por defecto), así que no necesita root. Si un exploit compromete el proceso, el atacante queda confinado al usuario fivem en lugar del sistema completo.
¿Cómo hago que el servidor espere a que MySQL suba antes de iniciar?
Añade `After=mysql.service` y `Requires=mysql.service` en la sección `[Unit]` del archivo .service. Para MariaDB usa `mariadb.service`. Esto hace que systemd solo inicie FiveM cuando la base de datos esté disponible — evita que el servidor arranque roto, falle la conexión y entre en bucle de reinicio.
¿Puedo usar txAdmin con systemd al mismo tiempo?
Sí, y de hecho es el patrón recomendado. El servicio systemd inicia txAdmin, y txAdmin gestiona el proceso FXServer internamente con auto-reinicio propio en caso de fallo. Ganas dos capas: systemd garantiza que txAdmin nunca muere, y txAdmin garantiza que FXServer se reinicia ante un fallo de recurso o un hang.
¿Cómo veo si el servidor se reinició solo durante la noche?
Usa `journalctl -u fivem.service --since '1 hour ago'` o `systemctl status fivem` — el conteo de reinicios y la marca de tiempo del último arranque están visibles. Para un historial más largo, `journalctl -u fivem.service --since yesterday | grep 'Started\|Stopped'` muestra todos los ciclos de arranque del día anterior.
¿Qué hago si el servidor entra en bucle de reinicio y satura la CPU?
Añade `StartLimitBurst=5` y `StartLimitIntervalSec=300` en la sección `[Unit]`. Esto hace que systemd deje de intentar reiniciar después de 5 fallos en 5 minutos, evitando consumir el 100% de la CPU en bucle. Investiga el motivo vía `journalctl -u fivem.service -n 200` antes de quitar el límite.