Configuring simple service with systemd
Clash Royale CLAN TAG#URR8PPP
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).
debian systemd configuration services
asked Jun 21 '16 at 16:06
Petr MensikPetr Mensik
2963519
add a comment |
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).
debian systemd configuration services
asked Jun 21 '16 at 16:06
Petr MensikPetr Mensik
2963519
Type=simplestill 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 startwould 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
add a comment |
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).
debian systemd configuration services
asked Jun 21 '16 at 16:06
Petr MensikPetr Mensik
2963519
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).
debian systemd configuration services
debian systemd configuration services
asked Jun 21 '16 at 16:06
Petr MensikPetr Mensik
2963519
asked Jun 21 '16 at 16:06
Petr MensikPetr Mensik
2963519
asked Jun 21 '16 at 16:06
Petr MensikPetr Mensik
2963519
asked Jun 21 '16 at 16:06
Petr MensikPetr Mensik
2963519
asked Jun 21 '16 at 16:06
Petr MensikPetr Mensik
2963519
2963519
Type=simplestill 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 startwould 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
add a comment |
Type=simplestill 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 startwould 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
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
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
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
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
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
add a comment |
1 Answer
1
active
oldest
votes
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).
answered Jun 24 '16 at 15:05
Mark StosbergMark Stosberg
3,9701126
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f291165%2fconfiguring-simple-service-with-systemd%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
answered Jun 24 '16 at 15:05
Mark StosbergMark Stosberg
3,9701126
add a comment |
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).
answered Jun 24 '16 at 15:05
Mark StosbergMark Stosberg
3,9701126
add a comment |
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).
answered Jun 24 '16 at 15:05
Mark StosbergMark Stosberg
3,9701126
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).
answered Jun 24 '16 at 15:05
Mark StosbergMark Stosberg
3,9701126
answered Jun 24 '16 at 15:05
Mark StosbergMark Stosberg
3,9701126
answered Jun 24 '16 at 15:05
Mark StosbergMark Stosberg
3,9701126
answered Jun 24 '16 at 15:05
Mark StosbergMark Stosberg
3,9701126
3,9701126
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f291165%2fconfiguring-simple-service-with-systemd%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Type=simplestill 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 startwould 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