Estamos usando o servidor Bamboo para integração contínua com agentes remotos que estão construindo nossos projetos. Esses agentes podem ser iniciados com um script de shell simples (que funciona bem). Mas pensei em ir ainda mais longe e torná-lo systemduma unidade que fará o agente iniciar automaticamente após a inicialização e permitirá que as pessoas o iniciem/parem por meio de systemctlcomandos. Então foi isso que eu tentei
[Unit]
Description=Atlassian Bamboo Agent
After=syslog.target network.target
[Service]
Type=forking
User=shub
Group=shub
ExecStart=/home/shub/bamboo-agent-home/bin/bamboo-agent.sh start
ExecStop=/home/shub/bamboo-agent-home/bin/bamboo-agent.sh stop
[Install]
WantedBy=multi-user.target
Do que eu fiz systemctl daemon-reload. O problema é que o agente não é inicializado após a reinicialização e também está agindo de forma estranha (de forma que o serviço se reinicia de vez em quando ou não funciona corretamente depois systemctl start). Então, o que estou fazendo de errado? Pensei em mudar Typepara o simplemodo como desejo que o agente seja executado como um serviço em segundo plano (e o próprio script executa o agente em segundo plano após a execução).
Responder1
Você fez várias perguntas. Responderei à pergunta: "Por que meu serviço systemd personalizado não inicia na inicialização?"
A resposta é porque você nãohabilitadoisto. Quando você executa systemctl enable my-service-name, o [Install]bloco em seu arquivo Unit é acionado.
Nesse caso, você instruiu o systemd a iniciar o serviço como parte do acesso ao arquivo multi-user.target.
A execução enabledo comando criará um link simbólico /etc/systemd/system/multi-user.target.wants/e a presença desse link simbólico é o que realmente instruirá systemdpara iniciar o serviço na inicialização.
Sugiro transformar seu comentário de "agir de maneira estranha" em uma pergunta separada, onde mais detalhes sejam fornecidos, talvez com detalhes do diário do systemd sobre o que está acontecendo. (verifique journalctla saída).