Como Ativar o Carregamento Automático de Scripts no Ubuntu: Três Métodos Prontos para Produção

Ativar o carregamento automático de scripts no Ubuntu significa configurar o sistema operativo para executar automaticamente um ou mais scripts de shell ou serviços no arranque do sistema, sem qualquer intervenção manual. Isto é conseguido através de três mecanismos principais: o diretório /etc/init.d/ baseado no SysVinit legado, o shim de compatibilidade /etc/rc.local, e o moderno framework de unidades de serviço systemd — sendo este último a abordagem autoritativa e recomendada em todas as versões do Ubuntu a partir da 15.04.

Para administradores de sistemas que executam cargas de trabalho num ambiente de VPS Hosting, a automatização do arranque não é uma conveniência — é um requisito de fiabilidade. Uma entrada de arranque automático mal configurada ou ausente significa que daemons críticos, agentes de monitorização, scripts de backup ou configurações de rede personalizadas falham silenciosamente ao iniciar após um reinício, causando interrupções de serviço difíceis de diagnosticar posteriormente.

Por Que a Automatização de Scripts de Arranque É Importante em Servidores Ubuntu

Cada servidor Ubuntu em produção acumula scripts operacionais ao longo do tempo: rotinas de pré-aquecimento de bases de dados, acionadores de rotação de logs, inicializadores de túneis VPN, carregadores de regras de firewall e verificações de saúde de aplicações. Sem um mecanismo de carregamento automático estruturado, estes scripts dependem inteiramente de execução manual — um único passo em falta após uma atualização do kernel ou reinício de emergência pode desencadear uma interrupção.

O ecossistema de automatização de arranque do Ubuntu evoluiu significativamente:

• SysVinit (anterior ao Ubuntu 15.04): Sequencial, lento, baseado em scripts. Cada serviço bloqueava o seguinte.
• Upstart (Ubuntu 6.10–15.04): Orientado a eventos, mais rápido, mas agora descontinuado.
• systemd (Ubuntu 15.04+): Ativação paralela de serviços, grafos de dependências, ativação por socket, controlo de recursos baseado em cgroup e registo estruturado via journald.

Compreender com qual camada está a trabalhar — e porquê — evita que implemente uma solução funcional num ambiente de teste que falha silenciosamente em produção.

Método 1: Utilizar o Diretório /etc/init.d/ (SysVinit / Scripts LSB)

Como Funciona

O diretório /etc/init.d/ é o local tradicional para scripts de inicialização Linux Standard Base (LSB). Cada script neste diretório é um script de shell que responde a comandos padronizados: start, stop, restart, status, e opcionalmente reload. O utilitário update-rc.d cria ligações simbólicas nos diretórios de nível de execução /etc/rcN.d/, determinando quando e em que ordem o script é executado durante as sequências de arranque e encerramento.

Nos sistemas Ubuntu modernos que executam systemd, estes scripts ainda são suportados através de uma camada de compatibilidade chamada systemd-sysv-generator, que converte automaticamente scripts de inicialização LSB em unidades systemd transitórias. Isto significa que os seus scripts /etc/init.d/ ainda serão executados, mas são geridos pelo systemd em vez de serem executados diretamente pelo SysVinit.

Implementação Passo a Passo

Passo 1: Criar o seu script

Escreva o seu script e certifique-se de que segue a convenção de cabeçalho LSB. Um exemplo mínimo e seguro para produção:

#!/bin/bash
### BEGIN INIT INFO
# Provides:          examplescript
# Required-Start:    $remote_fs $syslog $network
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Example autoload script
# Description:       Runs a custom initialization task at boot
### END INIT INFO

case "$1" in
  start)
    echo "Starting examplescript..."
    /usr/local/bin/examplescript.sh &
    ;;
  stop)
    echo "Stopping examplescript..."
    pkill -f examplescript.sh
    ;;
  restart)
    $0 stop
    $0 start
    ;;
  status)
    pgrep -f examplescript.sh > /dev/null && echo "Running" || echo "Stopped"
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|status}"
    exit 1
    ;;
esac
exit 0

Passo 2: Colocar o script em /etc/init.d/

sudo cp examplescript /etc/init.d/examplescript

Passo 3: Torná-lo executável

sudo chmod +x /etc/init.d/examplescript

Passo 4: Registá-lo no sistema de níveis de execução

sudo update-rc.d examplescript defaults

O argumento defaults regista o script para iniciar nos níveis de execução 2, 3, 4 e 5, e parar nos níveis de execução 0, 1 e 6 — o comportamento padrão para a maioria dos daemons de servidor.

Passo 5: Verificar o registo

ls -la /etc/rc2.d/ | grep examplescript

Deverá ver uma ligação simbólica como S01examplescript apontando de volta para /etc/init.d/examplescript.

Armadilha Crítica

O erro mais comum com este método é omitir o bloco de cabeçalho LSB. Sem ele, update-rc.d não consegue determinar a ordem de dependências, e systemd-sysv-generator pode atribuir uma ordem de execução incorreta relativamente à disponibilidade de rede ou montagens do sistema de ficheiros. Defina sempre as dependências Required-Start explicitamente.

Para remover o script do arranque automático sem o eliminar:

sudo update-rc.d examplescript disable

Para removê-lo completamente:

sudo update-rc.d examplescript remove

Método 2: Utilizar /etc/rc.local (Shim de Compatibilidade)

Como Funciona

/etc/rc.local é um mecanismo legado que executa um script de shell uma vez, após todos os serviços padrão de nível multi-utilizador terem iniciado. É o método de arranque automático mais simples possível — sem gestão de serviços, sem declarações de dependências, sem lógica de reinício. No Ubuntu 18.04 e posterior, o suporte a rc.local é fornecido pela unidade systemd rc-local.service, que está desativada por predefinição e deve ser explicitamente ativada.

Quando Utilizar

Utilize /etc/rc.local apenas para:

• Comandos de inicialização únicos que não precisam de ser geridos como serviços
• Prototipagem rápida ou testes antes de formalizar uma unidade systemd
• Exportações simples de variáveis de ambiente ou ajustes de parâmetros do kernel

Não utilize /etc/rc.local para daemons de longa duração. Como é executado de forma bloqueante e sequencial sem supervisão de processos, um comando suspenso em rc.local irá atrasar ou impedir a conclusão da sequência de arranque.

Implementação Passo a Passo

Passo 1: Verificar se /etc/rc.local existe

ls -la /etc/rc.local

Se não existir, crie-o:

sudo bash -c 'cat > /etc/rc.local << EOF
#!/bin/bash
exit 0
EOF'
sudo chmod +x /etc/rc.local

Passo 2: Ativar a unidade systemd rc-local (Ubuntu 18.04+)

sudo systemctl enable rc-local
sudo systemctl start rc-local

Passo 3: Adicionar o seu comando antes de exit 0

sudo nano /etc/rc.local

Insira o seu comando acima da linha exit 0:

#!/bin/bash
/usr/local/bin/examplescript.sh >> /var/log/examplescript.log 2>&1 &
exit 0

O & no final é essencial para qualquer comando de longa duração — coloca o processo em segundo plano para que rc.local não bloqueie.

Passo 4: Verificar a execução

sudo systemctl status rc-local

Armadilha Crítica

No Ubuntu 20.04 e 22.04, rc-local.service tem um tempo limite fixo de 30 segundos. Se o seu script demorar mais de 30 segundos a concluir, o systemd marcará o serviço como falhado e os comandos subsequentes em rc.local não serão executados. Redirecione a saída e coloque processos de longa duração explicitamente em segundo plano.

Método 3: Utilizar Unidades de Serviço systemd (Recomendado)

Por Que o systemd É a Abordagem Correta para Produção

systemd não é simplesmente um substituto do SysVinit — é um gestor completo de sistema e sessão que fornece resolução de dependências, arranque paralelo, ativação por socket e D-Bus, criação de serviços sob demanda, supervisão de processos com reinício automático, isolamento de recursos baseado em cgroup e agregação de logs estruturados através de journald. Para qualquer carga de trabalho a executar num Servidor Dedicado ou VPS em produção, as unidades systemd são o único mecanismo adequado para gerir scripts carregados automaticamente.

Anatomia de um Ficheiro de Unidade systemd

Um ficheiro de unidade .service está dividido em três secções obrigatórias:

• [Unit]: Metadados, descrição legível por humanos e declarações de dependências (After=, Requires=, Wants=).
• [Service]: Parâmetros de execução — o binário ou script a executar, o tipo de serviço, política de reinício, variáveis de ambiente e opções de isolamento de segurança.
• [Install]: Define qual o alvo systemd que ativa esta unidade (WantedBy=multi-user.target é o padrão para daemons de servidor).

Implementação Passo a Passo

Passo 1: Preparar o seu script

Certifique-se de que o seu script é executável e está localizado num caminho estável:

sudo cp examplescript.sh /usr/local/bin/examplescript.sh
sudo chmod +x /usr/local/bin/examplescript.sh

Passo 2: Criar o ficheiro de unidade

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

Um ficheiro de unidade de nível de produção com reforço de segurança:

[Unit]
Description=Example Autoload Script
Documentation=https://your-internal-wiki/examplescript
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/examplescript.sh
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
StandardOutput=journal
StandardError=journal
SyslogIdentifier=examplescript
User=nobody
Group=nogroup
NoNewPrivileges=true
ProtectSystem=strict
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Passo 3: Recarregar o daemon systemd

Após criar ou modificar qualquer ficheiro de unidade, deve recarregar o índice de configuração do daemon:

sudo systemctl daemon-reload

Passo 4: Ativar o serviço para arranque automático

sudo systemctl enable examplescript.service

Isto cria uma ligação simbólica em /etc/systemd/system/multi-user.target.wants/ apontando para o seu ficheiro de unidade.

Passo 5: Iniciar o serviço imediatamente

sudo systemctl start examplescript.service

Passo 6: Verificar o estado e os logs

sudo systemctl status examplescript.service
sudo journalctl -u examplescript.service -f

Compreender os Tipos de Serviço systemd

A diretiva Type= na secção [Service] é um dos parâmetros mais incompreendidos. Escolher o tipo errado faz com que o systemd reporte incorretamente a prontidão do serviço, levando a falhas de dependência.

Para um script que é executado uma vez no arranque e termina, utilize Type=oneshot com RemainAfterExit=yes para manter a unidade num estado “ativo” após a conclusão do script.

Avançado: Ordenação de Dependências com After= e Wants=

Uma falha comum em produção ocorre quando um script que requer conectividade de rede inicia antes de a pilha de rede estar totalmente inicializada. A cadeia de dependências correta para scripts dependentes de rede é:

After=network-online.target
Wants=network-online.target

Isto é distinto de After=network.target, que apenas garante que as interfaces de rede foram configuradas — não que estão efetivamente online e acessíveis. A dependência network-online.target requer que o systemd-networkd-wait-online.service ou equivalente confirme a conectividade.

Comparação: Os Três Métodos em Resumo

Erros Comuns e Como Evitá-los

Executar scripts como root desnecessariamente. As diretivas User= e Group= nos ficheiros de unidade systemd permitem reduzir privilégios. Um script que apenas precisa de escrever em /var/log/myapp/ não necessita de root — crie um utilizador de sistema dedicado e atribua a propriedade do diretório em conformidade.

Não redirecionar a saída em rc.local. Sem redirecionamento de saída, qualquer saída echo ou de erro dos comandos rc.local vai para a consola do sistema e é perdida. Acrescente sempre >> /var/log/yourscript.log 2>&1.

Utilizar caminhos absolutos de forma inconsistente. Os serviços systemd são executados num ambiente mínimo sem o PATH do utilizador. Utilize sempre caminhos absolutos para cada binário referenciado em ExecStart, incluindo interpretadores como /usr/bin/python3 ou /bin/bash.

Esquecer daemon-reload após editar ficheiros de unidade. O systemd armazena em cache o conteúdo dos ficheiros de unidade. Se editar um ficheiro .service e não executar sudo systemctl daemon-reload, o systemd continuará a utilizar a configuração antiga.

Colocar ficheiros de unidade em /lib/systemd/system/ para scripts personalizados. O diretório /lib/systemd/system/ é gerido pelo gestor de pacotes. Os ficheiros de unidade personalizados pertencem a /etc/systemd/system/, que tem precedência e sobrevive a atualizações de pacotes.

Matriz de Decisão Prática: Qual Método Utilizar

Utilize esta estrutura para selecionar o método adequado para o seu cenário específico:

• Daemon de longa duração que deve reiniciar em caso de falha — unidade systemd com Restart=on-failure
• Script de configuração único que deve concluir antes de outros serviços iniciarem — unidade systemd com Type=oneshot e dependências Before=
• Script que requer que a rede esteja totalmente online — unidade systemd com After=network-online.target
• Comando rápido para testes ou prototipagem — /etc/rc.local (temporariamente)
• Aplicação legada fornecida com um script de inicialização LSB — /etc/init.d/ com update-rc.d
• Qualquer coisa em produção — systemd, sempre

Para administradores que gerem múltiplos servidores Ubuntu, considere combinar a gestão de unidades systemd com ferramentas de gestão de configuração como o Ansible, que pode implementar e ativar ficheiros .service de forma idempotente em toda a sua frota. Se precisar de um ambiente gerido com acesso root completo para implementar estas configurações, o VPS Hosting com um Painel de Controlo VPS oferece a flexibilidade para gerir serviços systemd diretamente sem restrições.

Para equipas que executam cargas de trabalho com uso intensivo de recursos que requerem scripts de arranque para inicializar drivers GPU, ambientes CUDA ou servidores de inferência ML, os ambientes de GPU Hosting beneficiam particularmente das cadeias de dependências After= do systemd, garantindo que os drivers estão totalmente carregados antes de os serviços de aplicação tentarem vincular-se aos recursos de hardware.

Se os seus scripts carregados automaticamente interagem com configurações de servidor web ou rotinas de inicialização de bases de dados associadas a um ambiente de painel de controlo, as instalações de VPS com cPanel requerem cuidado extra — o cPanel gere a sua própria camada de supervisão de serviços, e as unidades systemd personalizadas devem ser definidas para evitar conflitos com os hooks de gestão de serviços do cPanel.

Lista de Verificação de Pontos-Chave Técnicos

Antes de implementar qualquer script de arranque num servidor Ubuntu, verifique o seguinte:

• Localização do ficheiro de unidade: Scripts personalizados vão em /etc/systemd/system/, não em /lib/systemd/system/
• Bit executável: Confirme com ls -la /path/to/script.sh — o bit x deve estar definido
• Caminhos absolutos: Cada binário em ExecStart utiliza um caminho completo; sem dependência de $PATH
• Declarações de dependências: After=network-online.target para qualquer script dependente de rede
• Tipo de serviço: Type=simple para daemons persistentes, Type=oneshot para scripts de execução e saída
• Minimização de privilégios: User=, Group=, NoNewPrivileges=true, ProtectSystem=strict
• Registo configurado: StandardOutput=journal e StandardError=journal para integração com journald
• daemon-reload executado: Execute sempre sudo systemctl daemon-reload após criar ou editar ficheiros de unidade
• Enable vs. start: enable cria a ligação simbólica de arranque automático; start executa-o imediatamente — ambos são necessários
• Testado com journalctl: Confirme a execução bem-sucedida com sudo journalctl -u yourservice.service --since "5 minutes ago"

FAQ

Qual é a diferença entre systemctl enable e systemctl start?

systemctl enable cria uma ligação simbólica que faz com que o serviço inicie automaticamente no próximo arranque. systemctl start inicia o serviço imediatamente na sessão atual. Normalmente, ambos os comandos são necessários ao configurar um novo serviço pela primeira vez.

Por que o meu serviço systemd falha com “executable not found” mesmo que o script exista?

Isto quase sempre significa que o caminho ExecStart está incorreto ou que o script não tem o bit executável. Verifique com which yourscript e ls -la /path/to/script. Confirme também que a primeira linha do seu script é um shebang válido (#!/bin/bash ou #!/usr/bin/env python3), pois o systemd não invoca um shell por predefinição para ExecStart.

Posso executar um script no arranque apenas uma vez, não em cada reinício?

Utilize Type=oneshot com uma diretiva ConditionPathExists=!/var/run/myscript.done na secção [Unit]. O script cria o ficheiro sentinela na primeira execução; os arranques subsequentes ignoram a execução porque a condição falha.

O /etc/rc.local ainda é suportado no Ubuntu 22.04?

Sim, mas está desativado por predefinição. Deve ativar manualmente a unidade rc-local.service com sudo systemctl enable rc-local e garantir que o ficheiro existe e é executável. É suportado como medida de compatibilidade, não como prática recomendada.

Como verifico por que um script de arranque falhou ao executar?

Execute sudo journalctl -u yourservice.service -b para ver todas as entradas de log dessa unidade desde o último arranque. Para falhas de rc.local, verifique sudo systemctl status rc-local.service e reveja /var/log/syslog para entradas com data/hora durante a sequência de arranque.