Opened 2 months ago
Last modified 8 weeks ago
#22037 new defect
VM desktop freeze
| Reported by: | systemdlete | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox-7.0.14 |
| Keywords: | Cc: | ||
| Guest type: | other | Host type: | other |
Description
Had a vbox VM freeze on me. This is very intermittent; I've had this about 5 or 6 times now, on different hosts. Looking at the host logs, I don't see any issues at the time of the incident. The VM logfile, and the VM's kern.log are attached.
VBox version is 7.0.14, and guest additions are in sync. The host is a FX8350 (8 cores) with 32GB RAM and generous disk space. MB is ASrock 970M Pro3. Host and VM run Devuan Daedalus (bookworm) with all the latest updates. Desktop on host and VM is xfce4.
I was not able to type anything into the VM desktop (host desktop continued to work fine, as did another VM). I tried using the input menu to send control sequences, but that did not work. I tried to pause and unpause the VM, because I thought that might jar whatever was sticking, but this did not help either. However, I was able to use ACPI shutdown to get the VM to close cleanly (aside from the freeze up).
Attachments (3)
Change History (8)
by , 2 months ago
| Attachment: | myvm0-2024-04-02-19-35-18.log added |
|---|
comment:1 by , 2 months ago
Hi systemdlete,
Hard to say at the moment if the issue is related to VBox or it is a guest side problem. Looks like guest graphics freeze btw. I think you still should be able to ssh to the guest. Could you please try to come up with steps to reproduce? Do you see something specious in host system logs?
comment:2 by , 2 months ago
As mentioned in my OP, I did not notice any anomalous behavior on the host system. Since I do not leave ssh running in this particular VM, I would not be able to connect to it. I'll see if I can configure a port for ssh for just this purpose, and I'll comb through the host logs again to see if I spot anything.
Thanks for looking at this. I realize these intermittent problems can be difficult, if not nearly impossible, to investigate and correct.
by , 2 months ago
| Attachment: | myvm0-2024-04-02-19-35-18.2.log added |
|---|
previous log file (I may have uploaded a more recent one than the log containing the crash, idk)
comment:3 by , 2 months ago
See the log I just uploaded. Because the logs don't give a clear indication of the day, and I tend to run my VMs for weeks at a time, I am never quite sure which log is which. I wish that vbox logging would intermittently insert a time stamp to give the reader some idea of which day it is (or is there an option to do this already?).
comment:4 by , 8 weeks ago
VM log files are not rotated while the VM is running, which means that everything in one VBox.log is always one VM run. At the beginning of a VBox.log (line 2) there's "Log opened ..." which establishes the correlation between the timestamps (which are relative to the process start - and it's crazy that you have VMs where the log begins 48 minutes (!) after the process was started. Either our code gets the process start time wrong or you have a system where the VM start takes many many times longer than usual. No idea why any of this would happen.
Anyway, some ages ago we created a tool for converting the timestamps to absolute: source:/trunk/tools/bin/vboxlogabstime.pl (it doesn't change the input, it outputs the whole log with absolute timestamps).
comment:5 by , 8 weeks ago
Yes I am aware of how the logs are rotated, etc. (though I forgot about the timestamp at he top of the file). What I meant, specifically, if I restart a VM several times, such as while investigating a problem, I may forget how many times I restarted it (usually not more than twice, but still...). So occasionally when submitting a report to support, I get them mixed up. I apologize for that.
Anyway, does the newer (correct) logfile reveal anything about the source of the problem I was experiencing?
VM Logfile