Como executar o seu programa como um serviço do systemd que arranca com o servidor

Para que um programa seu (uma aplicação Node.js, um script Python, um bot) arranque com o servidor e volte sozinho se cair, escreve-se um ficheiro de unidade em /etc/systemd/system/, recarrega-se o systemd e activa-se o serviço com systemctl enable --now. É a forma nativa de qualquer Linux moderno, sem instalar mais nada. Para aplicações Node.js existe ainda o PM2 (manter uma aplicação Node.js a correr com o PM2); o systemd serve para tudo o resto, e também para o Node.

Passo a passo

1 Corra o programa à mão primeiro. Se não arranca no terminal, também não arranca como serviço. Anote o caminho completo do programa (which node ou which python3) e a pasta de onde corre.
2 Crie um utilizador sem poderes para o serviço, em vez de o correr como root: sudo useradd --system --home /opt/meuapp --shell /usr/sbin/nologin meuapp. Se o programa for comprometido, o estrago fica preso a esse utilizador.
3 Escreva a unidade com sudo nano /etc/systemd/system/meuapp.service[Unit]
Description=A minha aplicação
After=network.target

[Service]
User=meuapp
WorkingDirectory=/opt/meuapp
ExecStart=/usr/bin/node /opt/meuapp/server.js
Restart=on-failure
RestartSec=5
EnvironmentFile=/etc/meuapp.env

[Install]
WantedBy=multi-user.target
4 Ponha os segredos num ficheiro à parte, /etc/meuapp.env, com uma linha NOME=valor por variável, e proteja-o: sudo chmod 600 /etc/meuapp.env. Veja variáveis de ambiente e segredos.
5 Diga ao systemd que há uma unidade nova e arranque-a: sudo systemctl daemon-reload e depois sudo systemctl enable --now meuapp. O “enable” faz arrancar com o servidor; o “--now” arranca já.
6 Confirme. systemctl status meuapp deve dizer “active (running)”, e journalctl -u meuapp -f mostra o que o programa escreve, em directo.
7 Prove o reinício. Reinicie o servidor numa hora calma e veja se o serviço volta. Só assim fica a saber que funciona.

As linhas da unidade, em palavras

Linha Para quê
After=network.target Só arranca depois de a rede estar pronta.
User= Quem corre o programa. Nunca root, a não ser que precise mesmo.
ExecStart= O comando, com o caminho completo do programa. O systemd não usa o seu PATH nem o seu terminal.
Restart=on-failure Volta a arrancar se terminar com erro; não volta se você o parou de propósito.
EnvironmentFile= Lê as variáveis de um ficheiro, em vez de as escrever na unidade (que qualquer utilizador pode ler).
WantedBy=multi-user.target É o que faz o enable arrancá-lo no arranque normal do servidor.
O ExecStart não é um terminal. Redirecções, && e ~ não funcionam como no terminal; use caminhos absolutos e, se precisar de vários comandos, ponha-os num script e execute o script. Se vir “status=203/EXEC”, o caminho está errado: ler o systemctl status.
Mudou a unidade e nada mudou? Falta o sudo systemctl daemon-reload. E uma unidade que dá “Permission denied” ao ler uma pasta é permissões ou o SELinux: permissões de ficheiros.
Reiniciar com um temporizador, em vez do cron: o systemd também agenda (ficheiros .timer), mas para tarefas simples o cron continua a ser o mais directo: quando o cron não corre.

O programa corre à mão e falha como serviço, e já leu o registo? Mostre-nos o texto do erro e o que mudou desde que funcionava.

Abrir um pedido de suporte

VEJA TAMBÉM

Um serviço não arranca: ler o systemctl status

Onde estão os registos num VPS Linux

Manter uma aplicação Node.js a correr com o PM2

Até onde vai o nosso suporte

PRODUTO RECOMENDADO

Alojamento de sites com cPanel

Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 321,75 MT/mês (plano de 3 anos, com cupão)

Ver planos
  • 0 Utilizadores acharam útil
Esta resposta foi útil?