1

We are using Bamboo server for continues integration with remote agents which are building our projects. These agent can be started up with a simple shell script (which works fine). But I thought I will move it even further and make it systemd unit which will make agent autostart after boot and it will allow people to start/stop it via systemctl commands. So this what I have tried

[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

Than I have done systemctl daemon-reload. Problem is that agent is not started up after reboot and also it's acting weird (in a way that service is restarting itself from time to time or don't come up properly after systemctl start). So what am I doing wrong? I thought about changing Type to simple however I want to agent run as a background service (and script itself runs agent on the background after execution).

|improve this question
  • Type=simple still runs as a background service, it just means that the service doesn't daemonize itself. – jordanm Jun 21 '16 at 16:14
  • Ok, so which one is more suitable for my use case? And can it explain the weird behaviour I am experiencing? – Petr Mensik Jun 21 '16 at 16:17
  • forking is likely correct in your case. If it was not, systemctl start would never return because it would wait for the service to fork indefinitely. You haven't provided enough information (eg logs) to diagnose your issues. – jordanm Jun 21 '16 at 17:03
  • Yeah, I understand that description is kinda vague. However, shouldn't service come up after reboot with this configuration? – Petr Mensik Jun 22 '16 at 7:31
1

You asked multiple questions. I'll answer the question: "Why doesn't my custom systemd service start at boot?"

The answer is because you haven't enabled it. When you run systemctl enable my-service-name, The [Install] block in your Unit file is acted upon.

In this case, you have instructed systemd to start up the service as part of reaching the multi-user.target.

Running enable command will create a symlink in /etc/systemd/system/multi-user.target.wants/ and the presence of that symlink is what will actually instruct systemd to start the service upon boot.

I suggest turning your "acting weird" comment into a separate question where more detail is provided, perhaps with details from the systemd journal about what's going on. (check journalctl output).

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.