Servidor SA-MP não inicia na VPS Linux: diagnóstico completo

Guia técnico pra diagnosticar e corrigir servidor SA-MP que não inicia em VPS Linux: segfault, libs faltando, permissões, porta ocupada e crash silencioso.

Servidor SA-MP que não inicia na VPS Linux é um dos problemas mais comuns de quem hospeda gamemode próprio. O binário oficial samp03svr foi compilado em 2015 pra Linux i386, e em distribuições modernas (Ubuntu 22.04+, Debian 12, AlmaLinux 9) ele esbarra em incompatibilidades de biblioteca, permissões e configuração de porta que produzem mensagens de erro confusas — quando produzem alguma.

Este guia cobre o diagnóstico sistemático: como capturar o erro real, identificar a causa raiz entre as cinco mais comuns (arquitetura errada, libs 32-bit faltando, permissões, porta ocupada, crash de plugin) e aplicar a correção certa. A persona alvo é o owner que já tem acesso root via SSH e quer entender o que está acontecendo, não só “fazer funcionar de qualquer jeito”.

Tempo estimado: 15-30 minutos pra rodar o diagnóstico completo, mais o tempo de aplicar a correção específica (de 2 minutos pra permissão até 20 minutos pra rebuild de plugin).

Pré-requisitos

Pré-requisitos

Você precisa de uma VPS Linux 64-bit com acesso root via SSH, o binário samp03svr (ou omp-server se for open.mp) já extraído num diretório, e o server.cfg configurado com pelo menos um gamemode válido. Este guia assume Ubuntu 22.04/24.04 ou Debian 12 — em distros RHEL-based (AlmaLinux, Rocky), substitua apt por dnf e os nomes de pacote.

Antes de começar, valide o ambiente básico:

Distro mínima Ubuntu 22.04 / Debian 12
Arquitetura x86_64 (com multiarch i386)
Porta default UDP 7777
RAM mínima 512 MB

Capturar o erro real antes de qualquer coisa

A primeira armadilha é assumir que “não inicia” significa “não dá output”. Quase sempre o binário está imprimindo o erro em stderr e sumindo de tela rápido demais — ou o erro está sendo descartado pela forma como você está rodando o servidor.

01

Entre no diretório do servidor e rode o binário em foreground, sem nenhum wrapper:

cd /home/samp/server
./samp03svr

Se aparecer “No such file or directory” mesmo com o arquivo presente (ls -la samp03svr confirma), você está com o problema clássico de libs 32-bit faltando — pule pra próxima seção. Se aparecer mensagem sobre plugin, gamemode ou porta, anote literalmente.

02

Se o terminal volta pro prompt sem nenhuma mensagem, capture stderr explicitamente:

./samp03svr 2> erro.log
cat erro.log

Saída vazia aqui significa segfault silencioso — o binário foi morto pelo kernel antes de imprimir qualquer coisa. Confirme rodando com strace:

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

A última linha antes do +++ killed by SIGSEGV +++ mostra qual arquivo o loader tentou abrir quando morreu — geralmente uma .so faltando.

Cuidado com nohup e screen

Se você sempre roda o servidor com nohup ./samp03svr & ou dentro de screen, o stderr pode estar indo pra nohup.out ou pra lugar nenhum. Pra diagnosticar, sempre teste primeiro em foreground com redirecionamento explícito.

Causa 1: libs 32-bit faltando (a mais comum)

O samp03svr é um ELF 32-bit i386. Numa VPS 64-bit moderna, o suporte multiarch não vem habilitado por padrão e o loader dinâmico do Linux não consegue resolver as dependências.

01

Confirme a arquitetura do binário:

file samp03svr

Saída esperada: ELF 32-bit LSB executable, Intel 80386. Se aparece ELF 64-bit, você está rodando uma build não-oficial — pule pra próxima seção.

02

Liste as dependências faltando:

ldd samp03svr

Se a saída tem linhas tipo libstdc++.so.6 => not found ou not a dynamic executable, faltam as libs 32-bit.

03

Habilite multiarch e instale as libs i386:

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

Em Debian 12, o pacote é lib32gcc-s1. Em Ubuntu 22.04, o mesmo nome funciona. Em distros RHEL-based, use dnf install -y glibc.i686 libstdc++.i686.

04

Confirme que resolveu:

ldd samp03svr
./samp03svr

Todas as linhas do ldd devem mostrar paths reais (não not found), e o binário deve subir até pelo menos imprimir o banner do SA-MP.

Causa 2: permissões erradas no binário ou no diretório

Permissão errada manifesta como “Permission denied” óbvio — mas também como “No such file or directory” quando o diretório intermediário não tem permissão de execução (bit x).

01

Garanta que o binário é executável:

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

Confirme que o usuário que vai rodar o servidor tem ownership do diretório inteiro. Assumindo usuário samp:

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

Se você está rodando como root (não recomendado — ver FAQ), pule este passo.

03

Diretórios scriptfiles/ e logs/ precisam de permissão de escrita:

chmod -R u+w scriptfiles logs gamemodes

Causa 3: porta UDP 7777 ocupada ou bloqueada

O SA-MP usa UDP 7777 por default. Se outro processo está escutando nessa porta — ou se o firewall está bloqueando — o servidor pode até subir e logo morrer, ou subir mas ficar inacessível externamente.

01

Verifique se a porta está livre antes de iniciar:

sudo ss -ulpn | grep 7777

Se retorna algo, outro processo está usando. Identifique o PID e decida: matar o processo ou trocar a porta no server.cfg (linha port).

02

Confirme que o firewall permite UDP 7777 entrando:

sudo ufw status
sudo ufw allow 7777/udp

Se você usa iptables direto:

sudo iptables -A INPUT -p udp --dport 7777 -j ACCEPT
Teste de fora

Pra confirmar que a porta está realmente acessível pela internet, rode de outra máquina: nmap -sU -p 7777 SEU_IP. Se aparecer open ou open|filtered e o servidor está rodando, está OK. Se aparecer closed, há firewall no caminho (datacenter, security group da nuvem, ou o próprio host).

Causa 4: crash de plugin no carregamento

Plugin incompatível com a versão do servidor ou com a glibc da VPS é a segunda causa mais comum. O sintoma típico: servidor imprime o banner, mostra “Loading plugin: X”, e some sem mais explicação.

01

Edite o server.cfg e comente todos os plugins (prefixe a linha com ; ou apague):

nano server.cfg

Procure a linha plugins ... e remova o conteúdo dela temporariamente, deixando só plugins (vazio).

02

Suba o servidor sem plugins. Se ele rodar, o problema é plugin. Volte ao server.cfg e adicione os plugins um por um, reiniciando entre cada adição, até reproduzir o crash. O último plugin adicionado é o culpado.

03

Pra plugins problemáticos, confirme a arquitetura:

file plugins/mysql.so

Deve ser ELF 32-bit (igual ao samp03svr). Plugin compilado 64-bit não carrega num servidor 32-bit. Baixe a versão correta do repositório oficial do plugin.

Verificação: confirmar que o servidor está respondendo

01

Com o servidor rodando, confirme que está escutando:

sudo ss -ulpn | grep 7777

Esperado: linha com samp03svr ou o PID do seu processo.

02

Verifique o log do próprio servidor:

tail -f server_log.txt

Procure por linhas tipo Started server on port 7777. Esse é o sinal definitivo de que o servidor está pronto pra aceitar conexões.

Resolução de problemas comuns

”Bind to UDP port 7777 failed”

Outro processo está usando a porta. Mude o port no server.cfg pra 7778 ou mate o processo conflitante (sudo lsof -i :7777 e kill -9 PID).

”Failed to allocate memory”

VPS com pouco RAM e gamemode pesado. Confirme com free -m. Se a RAM livre é < 100 MB, faça upgrade do plano ou habilite swap temporário (2 GB) pra confirmar que era memória mesmo o problema.

”Plugin failed to load”

Quase sempre incompatibilidade de glibc. Distros muito novas (Ubuntu 24.04) usam glibc 2.39, e plugins antigos foram compilados contra 2.27. Compile o plugin localmente ou use uma distro LTS mais conservadora (Ubuntu 22.04, Debian 11).

Não rode como root em produção

Rodar o servidor SA-MP como root expõe a VPS inteira em caso de exploit no binário ou em plugin. Crie um usuário dedicado (adduser samp) e configure um service systemd com User=samp.

Próximos passos

Com o servidor SA-MP rodando, vale endurecer a operação:

  • Configure um service systemd pra auto-restart em caso de crash
  • Habilite logrotate em server_log.txt pra não estourar disco
  • Migre o gamemode pra open.mp se quiser logs de crash mais detalhados
  • Configure backup automático da pasta scriptfiles/
  • Monitore a saúde do servidor via SA-MP query API

Se você está hospedando SA-MP em produção, planos de servidor de jogos da Hostini já vêm com Linux pré-configurado, multiarch habilitado e proteção DDoS no nível do datacenter — o que elimina as três causas mais comuns deste guia logo no provisionamento.

Perguntas frequentes

Por que o samp03svr roda direto no terminal mas falha em background?

Quando executado em foreground, o binário herda o TTY e mostra erros de carregamento. Em background (nohup, screen, systemd), erros de stderr podem ser engolidos. Sempre redirecione stderr pra arquivo (2> server-error.log) antes de assumir que o servidor 'simplesmente não sobe'.

Preciso mesmo de libc 32-bit numa VPS de 64-bit?

Sim. O binário oficial samp03svr é ELF 32-bit i386. Numa VPS Linux 64-bit (padrão moderno), você precisa do pacote multiarch (libc6:i386 + libstdc++6:i386). Sem isso, o erro é 'No such file or directory' mesmo com o arquivo presente, porque o loader 32-bit não existe.

Posso rodar o open.mp em vez do SA-MP original?

Pode, e geralmente é melhor pra servidores novos. O open.mp é compatível com gamemodes pawn antigos, tem binários nativos 64-bit e logging muito mais detalhado de crash. Mas o procedimento de diagnóstico (permissões, porta, plugins) é idêntico ao do SA-MP.

O servidor sobe, fica online por 30 segundos e morre. O que houve?

Quase sempre é crash de plugin durante o callback OnGameModeInit. Comente todas as linhas plugins no server.cfg, suba o servidor, e adicione plugins de volta um por um até reproduzir o crash. O culpado costuma ser MySQL R39+ ou plugins compilados pra outra ABI.

Como saber se a porta UDP 7777 está sendo bloqueada pelo firewall?

Rode 'sudo ufw status' ou 'sudo iptables -L -n | grep 7777'. Pra testar de fora, use 'nmap -sU -p 7777 SEU_IP' a partir de outra máquina. Se a porta aparece como 'open|filtered' mas o servidor não responde, o problema está no firewall do datacenter ou no security group.

É seguro rodar o servidor SA-MP como root?

Não. Em caso de exploit no binário ou em plugin, o atacante ganha shell root. Crie um usuário dedicado (adduser samp), dê ownership do diretório e rode o servidor sob esse usuário via systemd com User=samp. O ganho de segurança é alto e custa cinco minutos.

Tópicos:
Próximos passos VPS, dedicado ou painel gerenciado para FiveM, SAMP, MTA, Tibia e mais.Hospede seu servidor de jogos com a Hostini →
Esse tutorial foi útil?
Falar no WhatsApp