Servidor SA-MP no inicia en VPS Linux: diagnóstico completo

Guía técnica para diagnosticar y corregir un servidor SA-MP que no inicia en VPS Linux: segfault, librerías faltantes, permisos, puerto ocupado y crash silencioso.

Un servidor SA-MP que no inicia en VPS Linux es uno de los problemas más comunes para quien hospeda gamemode propio. El binario oficial samp03svr fue compilado en 2015 para Linux i386, y en distribuciones modernas (Ubuntu 22.04+, Debian 12, AlmaLinux 9) choca con incompatibilidades de librería, permisos y configuración de puerto que producen mensajes de error confusos — cuando producen alguno.

Esta guía cubre el diagnóstico sistemático: cómo capturar el error real, identificar la causa raíz entre las cinco más comunes (arquitectura incorrecta, librerías de 32 bits faltantes, permisos, puerto ocupado, crash de plugin) y aplicar la corrección adecuada. La persona objetivo es el owner que ya tiene acceso root vía SSH y quiere entender qué está pasando, no solo “hacer que funcione de cualquier manera”.

Tiempo estimado: 15-30 minutos para correr el diagnóstico completo, más el tiempo de aplicar la corrección específica (de 2 minutos para permisos hasta 20 minutos para recompilar un plugin).

Requisitos previos

Requisitos previos

Necesitas una VPS Linux de 64 bits con acceso root vía SSH, el binario samp03svr (o omp-server si es open.mp) ya extraído en un directorio, y server.cfg configurado con al menos un gamemode válido. Esta guía asume Ubuntu 22.04/24.04 o Debian 12 — en distros basadas en RHEL (AlmaLinux, Rocky), sustituye apt por dnf y los nombres de paquete.

Antes de empezar, valida el entorno básico:

Distro mínima Ubuntu 22.04 / Debian 12
Arquitectura x86_64 (con multiarch i386)
Puerto por defecto UDP 7777
RAM mínima 512 MB

Capturar el error real antes que nada

La primera trampa es asumir que “no inicia” significa “no muestra salida”. Casi siempre el binario está imprimiendo el error en stderr y desapareciendo de la pantalla demasiado rápido — o el error está siendo descartado por la forma en que estás corriendo el servidor.

01

Entra al directorio del servidor y ejecuta el binario en primer plano, sin ningún wrapper:

cd /home/samp/server
./samp03svr

Si aparece “No such file or directory” incluso con el archivo presente (ls -la samp03svr lo confirma), tienes el problema clásico de librerías de 32 bits faltantes — salta a la siguiente sección. Si aparece un mensaje sobre plugin, gamemode o puerto, anótalo literalmente.

02

Si la terminal vuelve al prompt sin ningún mensaje, captura stderr explícitamente:

./samp03svr 2> error.log
cat error.log

Salida vacía aquí significa segfault silencioso — el binario fue matado por el kernel antes de imprimir nada. Confirma ejecutándolo con strace:

sudo apt install -y strace
strace -f -e trace=openat,execve ./samp03svr 2>&1 | tail -30

La última línea antes del +++ killed by SIGSEGV +++ muestra qué archivo intentó abrir el loader cuando murió — generalmente un .so faltante.

Cuidado con nohup y screen

Si siempre corres el servidor con nohup ./samp03svr & o dentro de screen, el stderr puede estar yendo a nohup.out o a ninguna parte. Para diagnosticar, prueba siempre primero en primer plano con redirección explícita.

Causa 1: librerías de 32 bits faltantes (la más común)

samp03svr es un ELF 32-bit i386. En una VPS moderna de 64 bits, el soporte multiarch no viene habilitado por defecto y el loader dinámico de Linux no logra resolver las dependencias.

01

Confirma la arquitectura del binario:

file samp03svr

Salida esperada: ELF 32-bit LSB executable, Intel 80386. Si aparece ELF 64-bit, estás corriendo una build no oficial — salta a la siguiente sección.

02

Lista las dependencias faltantes:

ldd samp03svr

Si la salida tiene líneas tipo libstdc++.so.6 => not found o not a dynamic executable, faltan las librerías de 32 bits.

03

Habilita multiarch e instala las librerías i386:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y libc6:i386 libstdc++6:i386 lib32gcc-s1

En Debian 12, el paquete es lib32gcc-s1. En Ubuntu 22.04, el mismo nombre funciona. En distros basadas en RHEL, usa dnf install -y glibc.i686 libstdc++.i686.

04

Confirma que se resolvió:

ldd samp03svr
./samp03svr

Todas las líneas de ldd deben mostrar rutas reales (no not found), y el binario debe levantar al menos hasta imprimir el banner de SA-MP.

Causa 2: permisos erróneos en el binario o en el directorio

Un permiso incorrecto se manifiesta como “Permission denied” obvio — pero también como “No such file or directory” cuando el directorio intermedio no tiene permiso de ejecución (bit x).

01

Asegúrate de que el binario sea ejecutable:

chmod +x samp03svr
chmod +x plugins/*.so 2>/dev/null
02

Confirma que el usuario que va a correr el servidor tiene ownership del directorio completo. Asumiendo el usuario samp:

sudo chown -R samp:samp /home/samp/server

Si estás corriendo como root (no recomendado — ver FAQ), salta este paso.

03

Los directorios scriptfiles/ y logs/ necesitan permiso de escritura:

chmod -R u+w scriptfiles logs gamemodes

Causa 3: puerto UDP 7777 ocupado o bloqueado

SA-MP usa UDP 7777 por defecto. Si otro proceso está escuchando en ese puerto — o si el firewall está bloqueando — el servidor puede llegar a subir y morir enseguida, o subir pero quedar inaccesible externamente.

01

Verifica que el puerto esté libre antes de iniciar:

sudo ss -ulpn | grep 7777

Si devuelve algo, otro proceso lo está usando. Identifica el PID y decide: matar el proceso o cambiar el puerto en server.cfg (línea port).

02

Confirma que el firewall permite UDP 7777 entrante:

sudo ufw status
sudo ufw allow 7777/udp

Si usas iptables directamente:

sudo iptables -A INPUT -p udp --dport 7777 -j ACCEPT
Prueba desde afuera

Para confirmar que el puerto está realmente accesible por internet, ejecuta desde otra máquina: nmap -sU -p 7777 TU_IP. Si aparece open u open|filtered y el servidor está corriendo, está OK. Si aparece closed, hay un firewall en el camino (datacenter, security group de la nube, o el propio host).

Causa 4: crash de plugin durante la carga

Un plugin incompatible con la versión del servidor o con la glibc de la VPS es la segunda causa más común. El síntoma típico: el servidor imprime el banner, muestra “Loading plugin: X” y desaparece sin más explicación.

01

Edita server.cfg y comenta todos los plugins (prefija la línea con ; o bórrala):

nano server.cfg

Busca la línea plugins ... y quita su contenido temporalmente, dejando solo plugins (vacío).

02

Sube el servidor sin plugins. Si corre, el problema es un plugin. Vuelve a server.cfg y agrega los plugins uno por uno, reiniciando entre cada agregado, hasta reproducir el crash. El último plugin agregado es el culpable.

03

Para plugins problemáticos, confirma la arquitectura:

file plugins/mysql.so

Debe ser ELF 32-bit (igual que samp03svr). Un plugin compilado en 64 bits no carga en un servidor de 32 bits. Descarga la versión correcta del repositorio oficial del plugin.

Verificación: confirmar que el servidor está respondiendo

01

Con el servidor corriendo, confirma que está escuchando:

sudo ss -ulpn | grep 7777

Esperado: línea con samp03svr o el PID de tu proceso.

02

Verifica el log del propio servidor:

tail -f server_log.txt

Busca líneas tipo Started server on port 7777. Esa es la señal definitiva de que el servidor está listo para aceptar conexiones.

Resolución de problemas comunes

”Bind to UDP port 7777 failed”

Otro proceso está usando el puerto. Cambia port en server.cfg a 7778 o mata el proceso conflictivo (sudo lsof -i :7777 y kill -9 PID).

”Failed to allocate memory”

VPS con poca RAM y gamemode pesado. Confirma con free -m. Si la RAM libre es < 100 MB, haz upgrade de plan o habilita swap temporal (2 GB) para confirmar que efectivamente era cuestión de memoria.

”Plugin failed to load”

Casi siempre incompatibilidad de glibc. Distros muy nuevas (Ubuntu 24.04) usan glibc 2.39, y plugins antiguos fueron compilados contra 2.27. Compila el plugin localmente o usa una distro LTS más conservadora (Ubuntu 22.04, Debian 11).

No corras como root en producción

Correr el servidor SA-MP como root expone la VPS entera en caso de exploit en el binario o en algún plugin. Crea un usuario dedicado (adduser samp) y configura un service systemd con User=samp.

Siguientes pasos

Con el servidor SA-MP corriendo, vale la pena endurecer la operación:

  • Configura un service systemd para auto-restart en caso de crash
  • Habilita logrotate en server_log.txt para no llenar el disco
  • Migra el gamemode a open.mp si quieres logs de crash más detallados
  • Configura backup automático de la carpeta scriptfiles/
  • Monitorea la salud del servidor vía SA-MP query API

Si estás hospedando SA-MP en producción, los planes de servidor de juegos de Hostini ya vienen con Linux preconfigurado, multiarch habilitado y protección DDoS a nivel de datacenter — lo que elimina las tres causas más comunes de esta guía desde el provisionamiento.

Preguntas frecuentes

¿Por qué samp03svr corre directo en la terminal pero falla en segundo plano?

Cuando se ejecuta en primer plano, el binario hereda el TTY y muestra los errores de carga. En segundo plano (nohup, screen, systemd), los errores de stderr pueden quedar absorbidos. Siempre redirige stderr a un archivo (2> server-error.log) antes de asumir que el servidor 'simplemente no sube'.

¿Realmente necesito libc de 32 bits en una VPS de 64 bits?

Sí. El binario oficial samp03svr es ELF 32-bit i386. En una VPS Linux de 64 bits (estándar moderno), necesitas el paquete multiarch (libc6:i386 + libstdc++6:i386). Sin esto, el error es 'No such file or directory' incluso con el archivo presente, porque el loader de 32 bits no existe.

¿Puedo correr open.mp en lugar del SA-MP original?

Sí, y normalmente es mejor para servidores nuevos. open.mp es compatible con gamemodes pawn antiguos, tiene binarios nativos de 64 bits y un logging de crash mucho más detallado. Pero el procedimiento de diagnóstico (permisos, puerto, plugins) es idéntico al de SA-MP.

El servidor sube, queda en línea 30 segundos y muere. ¿Qué pasó?

Casi siempre es crash de plugin durante el callback OnGameModeInit. Comenta todas las líneas de plugins en server.cfg, sube el servidor y agrega plugins de vuelta uno por uno hasta reproducir el crash. El culpable suele ser MySQL R39+ o plugins compilados para otra ABI.

¿Cómo saber si el puerto UDP 7777 está siendo bloqueado por el firewall?

Ejecuta 'sudo ufw status' o 'sudo iptables -L -n | grep 7777'. Para probar desde afuera, usa 'nmap -sU -p 7777 TU_IP' desde otra máquina. Si el puerto aparece como 'open|filtered' pero el servidor no responde, el problema está en el firewall del datacenter o en el security group.

¿Es seguro correr el servidor SA-MP como root?

No. En caso de exploit en el binario o en algún plugin, el atacante obtiene shell root. Crea un usuario dedicado (adduser samp), dale ownership del directorio y corre el servidor bajo ese usuario vía systemd con User=samp. La ganancia de seguridad es alta y cuesta cinco minutos.

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