Log files in home directory - Is there a way to change location ?

[HulkySulky]

Hello,
Using Debian 11.3 / VB 6.1.34
I have a lot of log files directly in my home directory, very annoying. All files are either VBoxSVC.log or VBoxHeadless.log.

Is there a way to change those log's location ?

[scottgus1]

Yes, see https://www.virtualbox.org/manual/ch10. ... ata-global, about the VBOX_USER_HOME and/or XDG_CONFIG_HOME manually-made environment variables.

Virtualbox defaults to writing in "$HOME/.config/VirtualBox", not in "$HOME", so it appears that someone manually tweaked this before.

[HulkySulky]

Indeed I got log files in "$HOME/.config/VirtualBox", mainly "selectorwindow.log" and "VBoxSVC.log".

But I also got log files directly under $HOME, but strange ones. Very short (only a few lines). For example "2022-06-08-11-33-59.026-VBoxHeadless-7924.log" :

Code: Select all

Log created: 2022-06-08T11:33:59.268692000Z
Process ID:  7924 (0x1ef4)
Parent PID:  3862 (0xf16)
Executable:  /usr/lib/virtualbox/VBoxHeadless
Arg[0]: /usr/lib/virtualbox/VBoxHeadless
Arg[1]: --comment
Arg[2]: d11base
Arg[3]: --startvm
Arg[4]: e0d839c3-a811-41cd-96d6-cc2c45116453
Arg[5]: --vrde
Arg[6]: config
AddRef: illegal refcnt=3221225469 state=2

Nor VBOX_USER_HOME neither XDG_CONFIG_HOME exist. I created them manually, pointing them respectively to $HOME/.config/VirtualBox and to $HOME/.config, but to no effect. The log files are still created in $HOME

[klaus]

You're running into a not really known problem: your VM processes appear to crash because the code managing the lifetime of API objects has detected that the reference count should be increased again after it reached 0. Not a known issue.

To troubleshoot you'd need to enable core dumps for processes marked as "SUID", see https://www.virtualbox.org/wiki/Core_dump

If you could pass a core dump for such a crash we might be able to find out what's really going on and how to fix the issue.

[HulkySulky]

I just identified WHEN it happens.
I was doing some tests to find out the behavior of VB in case of logout, shutdown or reboot.

I thought the VMs are supposed to autosave in those cases, but it seems the OS doesn't always wait long enough. I started 3 VMs, then rebooted the system USING GNOME reboot menu. After reboot 2 VMs were saved, the third one aborted (and the third one is the one taking a little bit longer than the 2 others to save). And the following log appears in my HOME :

Code: Select all

Log created: 2022-06-08T16:44:04.465625000Z
Process ID:  11025 (0x2b11)
Parent PID:  4852 (0x12f4)
Executable:  /usr/lib/virtualbox/VBoxSVC
Arg[0]: /usr/lib/virtualbox/VBoxSVC
Arg[1]: --auto-shutdown
AddRef: illegal refcnt=3221225469 state=2

So it seems rebooting with gnome triggers savestate, but doesn't always have the time to do so.

Rebooting via console (sudo reboot) seems to trigger an acpi shutdown of the machines (they are all powered off after the reboot)

Using Debian 11.3 / Gnome 3.38 and VB 6.34.

[klaus]

Actually if you get logs for VBoxSVC ending with this line that means the VBox API service is running into an unexpected situation, effectively crashing. This also affects the running VMs, since without VBoxSVC they can't complete saving the state or shutting down. Your observed symptoms could be a side effect.

In any case, investigating this needs a core dump, and hopefully it tells us what's going the wrong way.

We've spent quite a bit of effort to get the OS shutdown case reasonably under control, but that's unfortunately far from perfect. Essentially there are two options how VirtualBox can react to shutdown events: it can veto them (which was the old VirtualBox behavior, and we got a lot of complaints about it), or it can just try its best to do something sensible with the VMs, which is trying to save state (since that tends to be faster than shutting the VM down). Unfortunately it usually gets very little time...

[HulkySulky]

I gave up on the idea of auto save, it's just too unreliable. I did a serie of tests with 5 running VMs, fairly memory heavy (about 4Gb of effectively used RAM each), 4 of them being clones of the first one, so identical VMs. Every host's reboot (made in identical conditions, as far as I can say) ends up in a different configuration, with usually 1 to 3 VMs in a saved state, and the rest in a powered off state. Sometimes some VMs are in an aborted state.

Also tried to make a systemd service, but it's the same, sometimes it works, sometimes not. I tried some tips and tricks that I found here and there on the web, for example adding ExecStop=/usr/bin/sleep 30, using KillMode=none, or enabling Linger for my user. Nothing works. Below the service file I tried, in case you have an idea.

In the end I decided to keep saving my VMs manually, and to use reboot-guard (https://github.com/ryran/reboot-guard) in case I forgot to shutdown or save a VM.

My service file (I start the service manually, as I don't always need this VM) :

Code: Select all

[Unit]
Description= Test VM

[Service]
User=username
Group=vboxusers
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/usr/bin/VBoxManage startvm testvm --type headless
ExecStop=/usr/bin/VBoxManage controlvm testvm savestate

[Install]
WantedBy=multi-user.target