Discussion:
Reliable way to finish system units before termination through systemd shutdown / reboot routines
(too old to reply)
Reiner Wenke
2017-08-15 14:25:30 UTC
Permalink
Raw Message
Hello,

I have running some virtualbox instances under systemd control and use vboxautostart-service
for starting and stopping (saving). This is running on Centos7
As long as I use systemctl stop vboxautostart-service for termination, everything is fine,
but it takes some time for completion.

If I shutdown or reboot the host system, then I get a premature kill of all running instances,
most likely through the systemd reboot / shutdown routines .
I tried some configuration changes, but nothing worked for me.

Is there a reliable way to avoid this behavior?

Best regards
Reiner
Reindl Harald
2017-08-15 20:15:36 UTC
Permalink
Raw Message
Post by Reiner Wenke
I have running some virtualbox instances under systemd control and use vboxautostart-service
for starting and stopping (saving). This is running on Centos7
As long as I use systemctl stop vboxautostart-service for termination, everything is fine,
but it takes some time for completion.
If I shutdown or reboot the host system, then I get a premature kill of all running instances,
most likely through the systemd reboot / shutdown routines .
I tried some configuration changes, but nothing worked for me.
Is there a reliable way to avoid this behavior?
you need to remember that the sequence of shutdown is the exactly verse
of startup to begin with and adjust "TimeoutStopSec" in case running
guests are suspended at shutdown

i finally throwed away anything from VMware Workstation including the
module-load stuffm dhcp and so on and solved it with own services,
tragtes and dependencies - below a part of the unit files to get an idea


[***@srv-rhsoft:~]$ cat /etc/systemd/system/vmware-guest.target
[Unit]
Description=VMware Guest Group
After=vmware.service vmware.target network-wan-bridge.service
display-manager.service
Requires=vmware.service vmware-modules.service vmware-vmnet.service
Wants=guest-arrakis.service
Wants=guest-testserver.service
Wants=display-manager.service

[Install]
WantedBy=graphical.target
____________________________________________

[***@srv-rhsoft:~]$ cat /etc/systemd/system/vmware.service
[Unit]
Description=VMware Workstation Service
Requires=vmware-modules.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/systemctl start vmware.target
ExecStop=-/scripts/vmware/vm-suspend-all.sh
ExecStop=/usr/bin/systemctl stop vmware.target
TimeoutSec=1800
TimeoutStopSec=1800
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_SYS_ADMIN
CAP_SYS_BOOT CAP_SYS_PTRACE

[Install]
WantedBy=multi-user.target
____________________________________________

[***@srv-rhsoft:~]$ cat /etc/systemd/system/vmware.target
[Unit]
Description=VMware Service Group
Requires=vmware-modules.service vmware-vmnet.service
Wants=vmware-authentication.service
Wants=vmware-usb.service

[Install]
WantedBy=multi-user.target
Lennart Poettering
2017-08-31 14:05:36 UTC
Permalink
Raw Message
Post by Reiner Wenke
Hello,
I have running some virtualbox instances under systemd control and use vboxautostart-service
for starting and stopping (saving). This is running on Centos7
As long as I use systemctl stop vboxautostart-service for termination, everything is fine,
but it takes some time for completion.
If I shutdown or reboot the host system, then I get a premature kill of all running instances,
most likely through the systemd reboot / shutdown routines .
I tried some configuration changes, but nothing worked for me.
Is there a reliable way to avoid this behavior?
At shutdown systemd will terminate all services in a similar way as
"systemctl stop" does it. I don#t really know vbox though, maybe they
are not setting everything up correctly there. Consider contacting
your downstream distro or the vbox community for help on this.

Lennart
--
Lennart Poettering, Red Hat
Rick Beldin
2017-08-31 15:36:25 UTC
Permalink
Raw Message
Post by Reiner Wenke
I have running some virtualbox instances under systemd control and use vboxautostart-service
for starting and stopping (saving). This is running on Centos7
As long as I use systemctl stop vboxautostart-service for termination, everything is fine,
but it takes some time for completion.
I'm going to guess that this causes vbox to attempt an acpi shutdown for each
guest. You may want to monitor the guest console as you do this to verify this.

Just a thought...

Rick
Andrei Borzenkov
2017-09-02 15:11:22 UTC
Permalink
Raw Message
Post by Reiner Wenke
Hello,
I have running some virtualbox instances under systemd control and use vboxautostart-service
for starting and stopping (saving). This is running on Centos7
As long as I use systemctl stop vboxautostart-service for termination, everything is fine,
but it takes some time for completion.
If I shutdown or reboot the host system, then I get a premature kill of all running instances,
most likely through the systemd reboot / shutdown routines .
I tried some configuration changes, but nothing worked for me.
Is there a reliable way to avoid this behavior?
It really depends on how VB starts services. My best guess (from
touching this in the past) is: when stopping VB startup script sends
request to each VM and exits. For systemd it means VB service has
completed and it cleans up by killing all remaining processes. You need
to debug what happens - then someone may come up with suggestion how to
fix it.
Reindl Harald
2017-09-02 16:06:56 UTC
Permalink
Raw Message
Post by Andrei Borzenkov
Post by Reiner Wenke
Hello,
I have running some virtualbox instances under systemd control and use vboxautostart-service
for starting and stopping (saving). This is running on Centos7
As long as I use systemctl stop vboxautostart-service for termination, everything is fine,
but it takes some time for completion.
If I shutdown or reboot the host system, then I get a premature kill of all running instances,
most likely through the systemd reboot / shutdown routines .
I tried some configuration changes, but nothing worked for me.
Is there a reliable way to avoid this behavior?
It really depends on how VB starts services. My best guess (from
touching this in the past) is: when stopping VB startup script sends
request to each VM and exits. For systemd it means VB service has
completed and it cleans up by killing all remaining processes. You need
to debug what happens - then someone may come up with suggestion how to
fix it
just try to suspend guests instead shutdown them via guest-tools

at least on vmware-workstation in that case it exits after the suspend
is finished while power off via guest-tools is asynchron

Loading...