systemd is ignoring ExecStop in the unit file, runs it as part of ExecStart
I am trying to have several VirtualBox images start automatically on boot and to be shutdown properly on host shutdown before powering down. I have a bash script, /usr/local/bin/vmctl.sh, that handles starting and stopping the guest images using calls to VBoxManage. The start call is very simple - it just runs through a list of images and calls VBoxManage startvm --type headless "<imgname>" then exits 0. The stop call cycles through the list and calls VBoxManage controlvm "<imgname>" acpipowerbutton then loops until VBoxManage list runningvms returns an empty list OR 60 seconds passes before it exits 0. Running the script from the command line works perfectly.
I have set up a unit file in /lib/systemd/system/vmctl.service:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
When I run systemctl start vmctl.service, it calls both the start and stop lines. When I call systemctl stop vmctl.service there is an entry in syslog that states Stopped VirtualBox Control but it does not do anything.
I am a total neophyte to systemd. I recently upgraded this Ubuntu box to 16.04. I'm pretty sure there's a simple explanation for this behaviour that I'm just not seeing.
Thanks!
Update based on Mark's suggestion:
I confirmed the syntax using systemd-analyze verify /etc/systemd/system/vmctl.service (after moving the file there - thanks for the tip). I then changed out the ExecStart and ExecStop as you suggested, ran systemctl daemon-reload and still see the same behaviour. The log shows both executing when calling systemctl start vmctl, but neither when running systemctl stop vmctl:
# journalctl -u vmctl | tail
.
.
.
Apr 06 19:28:18 macmi10-builder systemd[1]: Started VirtualBox Control.
Apr 06 19:28:18 macmi10-builder echo[13901]: I started
Apr 06 19:28:18 macmi10-builder echo[13904]: I stopped
Apr 06 19:28:33 macmi10-builder systemd[1]: Stopped VirtualBox Control.
16.04 virtualbox systemd
asked Apr 6 '17 at 0:51
Jay MacDonaldJay MacDonald
6113
add a comment |
I am trying to have several VirtualBox images start automatically on boot and to be shutdown properly on host shutdown before powering down. I have a bash script, /usr/local/bin/vmctl.sh, that handles starting and stopping the guest images using calls to VBoxManage. The start call is very simple - it just runs through a list of images and calls VBoxManage startvm --type headless "<imgname>" then exits 0. The stop call cycles through the list and calls VBoxManage controlvm "<imgname>" acpipowerbutton then loops until VBoxManage list runningvms returns an empty list OR 60 seconds passes before it exits 0. Running the script from the command line works perfectly.
I have set up a unit file in /lib/systemd/system/vmctl.service:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
When I run systemctl start vmctl.service, it calls both the start and stop lines. When I call systemctl stop vmctl.service there is an entry in syslog that states Stopped VirtualBox Control but it does not do anything.
I am a total neophyte to systemd. I recently upgraded this Ubuntu box to 16.04. I'm pretty sure there's a simple explanation for this behaviour that I'm just not seeing.
Thanks!
Update based on Mark's suggestion:
I confirmed the syntax using systemd-analyze verify /etc/systemd/system/vmctl.service (after moving the file there - thanks for the tip). I then changed out the ExecStart and ExecStop as you suggested, ran systemctl daemon-reload and still see the same behaviour. The log shows both executing when calling systemctl start vmctl, but neither when running systemctl stop vmctl:
# journalctl -u vmctl | tail
.
.
.
Apr 06 19:28:18 macmi10-builder systemd[1]: Started VirtualBox Control.
Apr 06 19:28:18 macmi10-builder echo[13901]: I started
Apr 06 19:28:18 macmi10-builder echo[13904]: I stopped
Apr 06 19:28:33 macmi10-builder systemd[1]: Stopped VirtualBox Control.
16.04 virtualbox systemd
asked Apr 6 '17 at 0:51
Jay MacDonaldJay MacDonald
6113
I actually had the same problem except that i had different script names, i set RemainAfterExit=yes and it worked.
– fins
May 13 '17 at 15:25
Did you ever get to the bottom of this?
– Jem Tucker
Jun 29 '17 at 8:29
add a comment |
I am trying to have several VirtualBox images start automatically on boot and to be shutdown properly on host shutdown before powering down. I have a bash script, /usr/local/bin/vmctl.sh, that handles starting and stopping the guest images using calls to VBoxManage. The start call is very simple - it just runs through a list of images and calls VBoxManage startvm --type headless "<imgname>" then exits 0. The stop call cycles through the list and calls VBoxManage controlvm "<imgname>" acpipowerbutton then loops until VBoxManage list runningvms returns an empty list OR 60 seconds passes before it exits 0. Running the script from the command line works perfectly.
I have set up a unit file in /lib/systemd/system/vmctl.service:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
When I run systemctl start vmctl.service, it calls both the start and stop lines. When I call systemctl stop vmctl.service there is an entry in syslog that states Stopped VirtualBox Control but it does not do anything.
I am a total neophyte to systemd. I recently upgraded this Ubuntu box to 16.04. I'm pretty sure there's a simple explanation for this behaviour that I'm just not seeing.
Thanks!
Update based on Mark's suggestion:
I confirmed the syntax using systemd-analyze verify /etc/systemd/system/vmctl.service (after moving the file there - thanks for the tip). I then changed out the ExecStart and ExecStop as you suggested, ran systemctl daemon-reload and still see the same behaviour. The log shows both executing when calling systemctl start vmctl, but neither when running systemctl stop vmctl:
# journalctl -u vmctl | tail
.
.
.
Apr 06 19:28:18 macmi10-builder systemd[1]: Started VirtualBox Control.
Apr 06 19:28:18 macmi10-builder echo[13901]: I started
Apr 06 19:28:18 macmi10-builder echo[13904]: I stopped
Apr 06 19:28:33 macmi10-builder systemd[1]: Stopped VirtualBox Control.
16.04 virtualbox systemd
asked Apr 6 '17 at 0:51
Jay MacDonaldJay MacDonald
6113
I am trying to have several VirtualBox images start automatically on boot and to be shutdown properly on host shutdown before powering down. I have a bash script, /usr/local/bin/vmctl.sh, that handles starting and stopping the guest images using calls to VBoxManage. The start call is very simple - it just runs through a list of images and calls VBoxManage startvm --type headless "<imgname>" then exits 0. The stop call cycles through the list and calls VBoxManage controlvm "<imgname>" acpipowerbutton then loops until VBoxManage list runningvms returns an empty list OR 60 seconds passes before it exits 0. Running the script from the command line works perfectly.
I have set up a unit file in /lib/systemd/system/vmctl.service:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
When I run systemctl start vmctl.service, it calls both the start and stop lines. When I call systemctl stop vmctl.service there is an entry in syslog that states Stopped VirtualBox Control but it does not do anything.
I am a total neophyte to systemd. I recently upgraded this Ubuntu box to 16.04. I'm pretty sure there's a simple explanation for this behaviour that I'm just not seeing.
Thanks!
Update based on Mark's suggestion:
I confirmed the syntax using systemd-analyze verify /etc/systemd/system/vmctl.service (after moving the file there - thanks for the tip). I then changed out the ExecStart and ExecStop as you suggested, ran systemctl daemon-reload and still see the same behaviour. The log shows both executing when calling systemctl start vmctl, but neither when running systemctl stop vmctl:
# journalctl -u vmctl | tail
.
.
.
Apr 06 19:28:18 macmi10-builder systemd[1]: Started VirtualBox Control.
Apr 06 19:28:18 macmi10-builder echo[13901]: I started
Apr 06 19:28:18 macmi10-builder echo[13904]: I stopped
Apr 06 19:28:33 macmi10-builder systemd[1]: Stopped VirtualBox Control.
16.04 virtualbox systemd
16.04 virtualbox systemd
asked Apr 6 '17 at 0:51
Jay MacDonaldJay MacDonald
6113
asked Apr 6 '17 at 0:51
Jay MacDonaldJay MacDonald
6113
edited Apr 7 '17 at 17:06
Jay MacDonald
asked Apr 6 '17 at 0:51
Jay MacDonaldJay MacDonald
6113
asked Apr 6 '17 at 0:51
Jay MacDonaldJay MacDonald
6113
asked Apr 6 '17 at 0:51
Jay MacDonaldJay MacDonald
6113
6113
I actually had the same problem except that i had different script names, i set RemainAfterExit=yes and it worked.
– fins
May 13 '17 at 15:25
Did you ever get to the bottom of this?
– Jem Tucker
Jun 29 '17 at 8:29
add a comment |
I actually had the same problem except that i had different script names, i set RemainAfterExit=yes and it worked.
– fins
May 13 '17 at 15:25
Did you ever get to the bottom of this?
– Jem Tucker
Jun 29 '17 at 8:29
I actually had the same problem except that i had different script names, i set RemainAfterExit=yes and it worked.
– fins
May 13 '17 at 15:25
I actually had the same problem except that i had different script names, i set RemainAfterExit=yes and it worked.
– fins
May 13 '17 at 15:25
Did you ever get to the bottom of this?
– Jem Tucker
Jun 29 '17 at 8:29
Did you ever get to the bottom of this?
– Jem Tucker
Jun 29 '17 at 8:29
add a comment |
4 Answers
4
active
oldest
votes
Your systemd syntax is correct. Your problem is elsewhere.
First, you can confirm that the syntax itself is correct with:
systemd-analyze verify /path/to/your/vmctl.service
Second, try substituting these lines:
ExecStart=/bin/echo "I started"
ExecStop=/bin/echo "I stopped"
After running systemctl start vmctl or systemctl stop vmctl, use journalctl -u vmctl to check the logs. I expect you'll confirm systemd ran the correct commands.
Also /lib/systemd/system is intended for a place for packages to manage systemd files. Files that human's modify and manually manage are intended to go in /etc/systemd/system
answered Apr 6 '17 at 13:58
Mark StosbergMark Stosberg
2,26811527
After substituting those commands into a simple or forking service, the same behavior is reflected. For simple,ExecStart's echo exits, so it callsExecStop. For forking, there are no running child processes fromExecStart's echo, and as such it callsExecStop.
– Duncan X Simpson
Jan 22 '18 at 15:05
add a comment |
As others have mentioned, the problem is that vmctl.sh immediately exits. Contrary to @Christophe's answer, forking will not work most likely, as vmctl.sh likely does not fork. What you need is a oneshot service, with RemainAfterExit=true. If you just change it to oneshot, you'll get the exact same behavior. The RemainAfterExit part tells it that even after the ExecStart exits, the service should still be considered running, so it should not run the ExecStop(s).
answered Jan 22 '18 at 15:01
Duncan X SimpsonDuncan X Simpson
353316
omg lifesaver, oneshot worked perfect for vncserver service :D thank you.
– erm3nda
Mar 31 '18 at 0:03
add a comment |
The default Type setting for a Service unit is Type=simple, which is used when the process configured with ExecStart= is the main process of the service. Such a unit will wait until the process specified by ExecStart returns, then deactivate by running the process specified by ExecStop. In your case, this will happen as soon as the virtual machines have been launched (not what you want).
Type=forking is used when the process specified by ExecStart is expected to exit after start-up is complete, while its child process(es) continue(s) to run in the background. This is the behavior of traditional UNIX daemons and the recommended choice in your case. The process specified by ExecStop will run in case the service crashes or upon the “systemctl stop vmctl” command.
So your unit file should be:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
Type=forking
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
answered Oct 4 '17 at 19:14
ChristopheChristophe
91
Thevmctl.shscript is not a daemon - it's a controller, and likely does not fork.
– Duncan X Simpson
Jan 22 '18 at 15:01
add a comment |
you are missing
RemainAfterExit=true
answered 20 mins ago
ninjaninja
11
New contributor
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2faskubuntu.com%2fquestions%2f900628%2fsystemd-is-ignoring-execstop-in-the-unit-file-runs-it-as-part-of-execstart%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Your systemd syntax is correct. Your problem is elsewhere.
First, you can confirm that the syntax itself is correct with:
systemd-analyze verify /path/to/your/vmctl.service
Second, try substituting these lines:
ExecStart=/bin/echo "I started"
ExecStop=/bin/echo "I stopped"
After running systemctl start vmctl or systemctl stop vmctl, use journalctl -u vmctl to check the logs. I expect you'll confirm systemd ran the correct commands.
Also /lib/systemd/system is intended for a place for packages to manage systemd files. Files that human's modify and manually manage are intended to go in /etc/systemd/system
answered Apr 6 '17 at 13:58
Mark StosbergMark Stosberg
2,26811527
After substituting those commands into a simple or forking service, the same behavior is reflected. For simple,ExecStart's echo exits, so it callsExecStop. For forking, there are no running child processes fromExecStart's echo, and as such it callsExecStop.
– Duncan X Simpson
Jan 22 '18 at 15:05
add a comment |
Your systemd syntax is correct. Your problem is elsewhere.
First, you can confirm that the syntax itself is correct with:
systemd-analyze verify /path/to/your/vmctl.service
Second, try substituting these lines:
ExecStart=/bin/echo "I started"
ExecStop=/bin/echo "I stopped"
After running systemctl start vmctl or systemctl stop vmctl, use journalctl -u vmctl to check the logs. I expect you'll confirm systemd ran the correct commands.
Also /lib/systemd/system is intended for a place for packages to manage systemd files. Files that human's modify and manually manage are intended to go in /etc/systemd/system
answered Apr 6 '17 at 13:58
Mark StosbergMark Stosberg
2,26811527
After substituting those commands into a simple or forking service, the same behavior is reflected. For simple,ExecStart's echo exits, so it callsExecStop. For forking, there are no running child processes fromExecStart's echo, and as such it callsExecStop.
– Duncan X Simpson
Jan 22 '18 at 15:05
add a comment |
Your systemd syntax is correct. Your problem is elsewhere.
First, you can confirm that the syntax itself is correct with:
systemd-analyze verify /path/to/your/vmctl.service
Second, try substituting these lines:
ExecStart=/bin/echo "I started"
ExecStop=/bin/echo "I stopped"
After running systemctl start vmctl or systemctl stop vmctl, use journalctl -u vmctl to check the logs. I expect you'll confirm systemd ran the correct commands.
Also /lib/systemd/system is intended for a place for packages to manage systemd files. Files that human's modify and manually manage are intended to go in /etc/systemd/system
answered Apr 6 '17 at 13:58
Mark StosbergMark Stosberg
2,26811527
Your systemd syntax is correct. Your problem is elsewhere.
First, you can confirm that the syntax itself is correct with:
systemd-analyze verify /path/to/your/vmctl.service
Second, try substituting these lines:
ExecStart=/bin/echo "I started"
ExecStop=/bin/echo "I stopped"
After running systemctl start vmctl or systemctl stop vmctl, use journalctl -u vmctl to check the logs. I expect you'll confirm systemd ran the correct commands.
Also /lib/systemd/system is intended for a place for packages to manage systemd files. Files that human's modify and manually manage are intended to go in /etc/systemd/system
answered Apr 6 '17 at 13:58
Mark StosbergMark Stosberg
2,26811527
edited Jan 22 '18 at 16:31
answered Apr 6 '17 at 13:58
Mark StosbergMark Stosberg
2,26811527
answered Apr 6 '17 at 13:58
Mark StosbergMark Stosberg
2,26811527
answered Apr 6 '17 at 13:58
Mark StosbergMark Stosberg
2,26811527
2,26811527
After substituting those commands into a simple or forking service, the same behavior is reflected. For simple,ExecStart's echo exits, so it callsExecStop. For forking, there are no running child processes fromExecStart's echo, and as such it callsExecStop.
– Duncan X Simpson
Jan 22 '18 at 15:05
add a comment |
After substituting those commands into a simple or forking service, the same behavior is reflected. For simple,ExecStart's echo exits, so it callsExecStop. For forking, there are no running child processes fromExecStart's echo, and as such it callsExecStop.
– Duncan X Simpson
Jan 22 '18 at 15:05
After substituting those commands into a simple or forking service, the same behavior is reflected. For simple,
ExecStart's echo exits, so it calls ExecStop. For forking, there are no running child processes from ExecStart's echo, and as such it calls ExecStop.– Duncan X Simpson
Jan 22 '18 at 15:05
After substituting those commands into a simple or forking service, the same behavior is reflected. For simple,
ExecStart's echo exits, so it calls ExecStop. For forking, there are no running child processes from ExecStart's echo, and as such it calls ExecStop.– Duncan X Simpson
Jan 22 '18 at 15:05
add a comment |
As others have mentioned, the problem is that vmctl.sh immediately exits. Contrary to @Christophe's answer, forking will not work most likely, as vmctl.sh likely does not fork. What you need is a oneshot service, with RemainAfterExit=true. If you just change it to oneshot, you'll get the exact same behavior. The RemainAfterExit part tells it that even after the ExecStart exits, the service should still be considered running, so it should not run the ExecStop(s).
answered Jan 22 '18 at 15:01
Duncan X SimpsonDuncan X Simpson
353316
omg lifesaver, oneshot worked perfect for vncserver service :D thank you.
– erm3nda
Mar 31 '18 at 0:03
add a comment |
As others have mentioned, the problem is that vmctl.sh immediately exits. Contrary to @Christophe's answer, forking will not work most likely, as vmctl.sh likely does not fork. What you need is a oneshot service, with RemainAfterExit=true. If you just change it to oneshot, you'll get the exact same behavior. The RemainAfterExit part tells it that even after the ExecStart exits, the service should still be considered running, so it should not run the ExecStop(s).
answered Jan 22 '18 at 15:01
Duncan X SimpsonDuncan X Simpson
353316
omg lifesaver, oneshot worked perfect for vncserver service :D thank you.
– erm3nda
Mar 31 '18 at 0:03
add a comment |
As others have mentioned, the problem is that vmctl.sh immediately exits. Contrary to @Christophe's answer, forking will not work most likely, as vmctl.sh likely does not fork. What you need is a oneshot service, with RemainAfterExit=true. If you just change it to oneshot, you'll get the exact same behavior. The RemainAfterExit part tells it that even after the ExecStart exits, the service should still be considered running, so it should not run the ExecStop(s).
answered Jan 22 '18 at 15:01
Duncan X SimpsonDuncan X Simpson
353316
As others have mentioned, the problem is that vmctl.sh immediately exits. Contrary to @Christophe's answer, forking will not work most likely, as vmctl.sh likely does not fork. What you need is a oneshot service, with RemainAfterExit=true. If you just change it to oneshot, you'll get the exact same behavior. The RemainAfterExit part tells it that even after the ExecStart exits, the service should still be considered running, so it should not run the ExecStop(s).
answered Jan 22 '18 at 15:01
Duncan X SimpsonDuncan X Simpson
353316
answered Jan 22 '18 at 15:01
Duncan X SimpsonDuncan X Simpson
353316
answered Jan 22 '18 at 15:01
Duncan X SimpsonDuncan X Simpson
353316
answered Jan 22 '18 at 15:01
Duncan X SimpsonDuncan X Simpson
353316
353316
omg lifesaver, oneshot worked perfect for vncserver service :D thank you.
– erm3nda
Mar 31 '18 at 0:03
add a comment |
omg lifesaver, oneshot worked perfect for vncserver service :D thank you.
– erm3nda
Mar 31 '18 at 0:03
omg lifesaver, oneshot worked perfect for vncserver service :D thank you.
– erm3nda
Mar 31 '18 at 0:03
omg lifesaver, oneshot worked perfect for vncserver service :D thank you.
– erm3nda
Mar 31 '18 at 0:03
add a comment |
The default Type setting for a Service unit is Type=simple, which is used when the process configured with ExecStart= is the main process of the service. Such a unit will wait until the process specified by ExecStart returns, then deactivate by running the process specified by ExecStop. In your case, this will happen as soon as the virtual machines have been launched (not what you want).
Type=forking is used when the process specified by ExecStart is expected to exit after start-up is complete, while its child process(es) continue(s) to run in the background. This is the behavior of traditional UNIX daemons and the recommended choice in your case. The process specified by ExecStop will run in case the service crashes or upon the “systemctl stop vmctl” command.
So your unit file should be:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
Type=forking
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
answered Oct 4 '17 at 19:14
ChristopheChristophe
91
Thevmctl.shscript is not a daemon - it's a controller, and likely does not fork.
– Duncan X Simpson
Jan 22 '18 at 15:01
add a comment |
The default Type setting for a Service unit is Type=simple, which is used when the process configured with ExecStart= is the main process of the service. Such a unit will wait until the process specified by ExecStart returns, then deactivate by running the process specified by ExecStop. In your case, this will happen as soon as the virtual machines have been launched (not what you want).
Type=forking is used when the process specified by ExecStart is expected to exit after start-up is complete, while its child process(es) continue(s) to run in the background. This is the behavior of traditional UNIX daemons and the recommended choice in your case. The process specified by ExecStop will run in case the service crashes or upon the “systemctl stop vmctl” command.
So your unit file should be:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
Type=forking
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
answered Oct 4 '17 at 19:14
ChristopheChristophe
91
Thevmctl.shscript is not a daemon - it's a controller, and likely does not fork.
– Duncan X Simpson
Jan 22 '18 at 15:01
add a comment |
The default Type setting for a Service unit is Type=simple, which is used when the process configured with ExecStart= is the main process of the service. Such a unit will wait until the process specified by ExecStart returns, then deactivate by running the process specified by ExecStop. In your case, this will happen as soon as the virtual machines have been launched (not what you want).
Type=forking is used when the process specified by ExecStart is expected to exit after start-up is complete, while its child process(es) continue(s) to run in the background. This is the behavior of traditional UNIX daemons and the recommended choice in your case. The process specified by ExecStop will run in case the service crashes or upon the “systemctl stop vmctl” command.
So your unit file should be:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
Type=forking
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
answered Oct 4 '17 at 19:14
ChristopheChristophe
91
The default Type setting for a Service unit is Type=simple, which is used when the process configured with ExecStart= is the main process of the service. Such a unit will wait until the process specified by ExecStart returns, then deactivate by running the process specified by ExecStop. In your case, this will happen as soon as the virtual machines have been launched (not what you want).
Type=forking is used when the process specified by ExecStart is expected to exit after start-up is complete, while its child process(es) continue(s) to run in the background. This is the behavior of traditional UNIX daemons and the recommended choice in your case. The process specified by ExecStop will run in case the service crashes or upon the “systemctl stop vmctl” command.
So your unit file should be:
[Unit]
Description=VirtualBox Control
After=virtualbox.service
[Service]
Type=forking
ExecStart=/usr/local/bin/vmctl.sh start
ExecStop=/usr/local/bin/vmctl.sh stop
[Install]
WantedBy=multi-user.target
answered Oct 4 '17 at 19:14
ChristopheChristophe
91
answered Oct 4 '17 at 19:14
ChristopheChristophe
91
answered Oct 4 '17 at 19:14
ChristopheChristophe
91
answered Oct 4 '17 at 19:14
ChristopheChristophe
91
91
Thevmctl.shscript is not a daemon - it's a controller, and likely does not fork.
– Duncan X Simpson
Jan 22 '18 at 15:01
add a comment |
Thevmctl.shscript is not a daemon - it's a controller, and likely does not fork.
– Duncan X Simpson
Jan 22 '18 at 15:01
The
vmctl.sh script is not a daemon - it's a controller, and likely does not fork.– Duncan X Simpson
Jan 22 '18 at 15:01
The
vmctl.sh script is not a daemon - it's a controller, and likely does not fork.– Duncan X Simpson
Jan 22 '18 at 15:01
add a comment |
you are missing
RemainAfterExit=true
answered 20 mins ago
ninjaninja
11
New contributor
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
you are missing
RemainAfterExit=true
answered 20 mins ago
ninjaninja
11
New contributor
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
you are missing
RemainAfterExit=true
answered 20 mins ago
ninjaninja
11
New contributor
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
you are missing
RemainAfterExit=true
answered 20 mins ago
ninjaninja
11
New contributor
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 20 mins ago
ninjaninja
11
New contributor
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 20 mins ago
ninjaninja
11
answered 20 mins ago
ninjaninja
11
11
New contributor
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
ninja is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- 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%2faskubuntu.com%2fquestions%2f900628%2fsystemd-is-ignoring-execstop-in-the-unit-file-runs-it-as-part-of-execstart%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
I actually had the same problem except that i had different script names, i set RemainAfterExit=yes and it worked.
– fins
May 13 '17 at 15:25
Did you ever get to the bottom of this?
– Jem Tucker
Jun 29 '17 at 8:29