El jue, 1 sept 2022 a las 19:35, Silvio Knizek (<killermoe...@gmx.net>)
escribió:
> Am Donnerstag, dem 01.09.2022 um 19:17 -0300 schrieb Sergio Belkin:
> >
> >
> >
> > El jue, 1 sept 2022 a las 16:22, Silvio Knizek
> > (<killermoe...@gmx.net>) escribió:
> > > Am Donnerstag, dem 01.09.2022 um 14:59 -0300 schrieb Sergio Belkin:
> > > >
> > > > This is the unit file:
> > > > [Unit]
> > > > Description=VirtualBox VM %i
> > > > After=network.target vboxdrv.service
> > > > Before=runlevel2.target shutdown.target
> > > >
> > > > [Service]
> > > > Type=forking
> > > > Restart=no
> > > > TimeoutSec=5min
> > > > IgnoreSIGPIPE=no
> > > > KillMode=process
> > > > GuessMainPID=no
> > > > RemainAfterExit=no
> > > >
> > > > #ExecStart=/usr/lib/virtualbox/VBoxHeadless --comment RHEL7 --
> > > > startvm
> > > > f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config
> > > > ExecStart=/usr/bin/VBoxManage startvm %i --type headless
> > > > ExecStop=/usr/bin/VBoxManage controlvm %i acpipowerbutton
> > > >
> > > > [Install]
> > > > WantedBy=default.target
> > > >
> > > > (End of file)
> > > >
> > > > What is the proper way to configure this kind of unit?
> > > >
> > > > Thanks in advance
> > > >
> > > Is this really a forking process? Or do you just instruct some
> > > daemon
> > > via a RPC call to start your VM? In this case no actuall process
> > > would
> > > be there.
> > > If there is a forking process, can you instruct VBoxManage to run
> > > in
> > > the foreground?
> > > Or do you need to start some daemon process first and if not
> > > already
> > > running, than VBoxManage does so? This would explain the lingering
> > > processes.
> > > In generall your KillMode=process is what keeps the other processes
> > > running in the cgroup. Just remove it.
> > >
> > > Also, your Before= line is bogus. And if your vboxdrv.service just
> > > contains the lines to load the vbox modules, you would be far
> > > better of
> > > with some snippet in /etc/modules-load.d
> > >
> > > Oh, and as you run in user mode, _all_ your Before= and After=
> > > entries
> > > are useless, as user units can't see and reference system units.
> > >
> > > So yeah, your goal would be to see how you can actually start the
> > > VM
> > > process via CLI and nothing else.
> > >
> > > BR
> > > Silvio
> >
> > Hi Silvio,
> > Nice answer.
> > How to tell if it is a forking process?
> > The command "/usr/bin/VBoxManage startvm RHEL7 --type headless"
> > exits and then it runs "/usr/bin/VBoxManage startvm RHEL7 --type
> > headles"
> >
> > Thanks again!
>
> Hi,
>
> please keep answers on-list.
> For your message, I don't understand it. The command forks/exists and
> runs itself? Or did you copy it wrong the second time? Has VBoxManage
> other command line parameters you can use for _not_ forking?
>
Hi, Silvio, sorry by sending mail out-of-list.
This what happens if I launch by hand:
$ /usr/bin/VBoxManage startvm RHEL7 --type headless
Waiting for VM "RHEL7" to power on...
VM "RHEL7" has been successfully started. pstree --show-parents 72650
So I search the process:
$ ps aux | grep -i VB
root 1088 0.0 0.0 0 0 ? I< 13:43 0:00
[iprt-VBoxWQueue]
root 1097 0.0 0.0 0 0 ? S 13:43 0:00
[iprt-VBoxTscThread]
sergio 72594 0.0 0.0 252628 10300 ? S 17:31 0:00
/usr/lib/virtualbox/VBoxXPCOMIPCD
sergio 72600 0.0 0.0 797244 21784 ? Sl 17:31 0:00
/usr/lib/virtualbox/VBoxSVC --auto-shutdown
sergio 72650 7.7 0.7 2445132 252568 ? Sl 17:31 0:39
/usr/lib/virtualbox/VBoxHeadless --comment RHEL7 --startvm
f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config
sergio 77185 0.0 0.0 222312 2220 pts/1 S+ 17:40 0:00 grep
--color=auto -i VB
The relevant process it seems to be 72650, so if I list the process tree
$ pstree --show-parents 72650
systemd───systemd───VBoxSVC───VBoxHeadless───24*[{VBoxHeadless}]
So I've edited the unit file in this way:
[Unit]
Description=VirtualBox VM %i
[Service]
Type=simple
KillMode=mixed
ExecStart=/usr/lib/virtualbox/VBoxHeadless --comment RHEL7 --startvm
f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config
#ExecStop=/usr/bin/VBoxManage controlvm %i acpipowerbutton
[Install]
WantedBy=default.target
#(End of file)
I don't know exactly why but I had to set KillMode to mixed, and the more
counterintuitive for me was commenting out the ExecStop line, otherwise I
would have to start the service twice. I'm amazed how systemd stops the
service in the right way. it works even if I run poweroff within the VM,
systemd is aware that it's stopped...
Only final thing to mention: I've installed the acpid package on the guest
(I didn't test sufficiently without it).
HTH
Cheers
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
