Debian freezes after 20-30 minutes of use on OS X host

[foice]

Hi I have running copy of Debian Stretch as guest on my OS X host. Since a few days I have noted that the guest Debian system freezes at random after tens of minutes of usage, typically when I have a few programs running (e.g. several tabs in the browser), but I cannot say for sure is related to the amount of load.

I am running VirtualBox 5.2.6 and uname -a on the guest returns
4.9.0-5-amd64 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)

Am I alone with these freezes? I read that they have happened to other users before, but the latest message on this seems to be 18 months old ...

Let me know if there is more info I can provide on the system status at the freeze time.
Best,
Roberto

[andyp73]

Since a few days I have noted that the guest Debian system freezes at random after tens of minutes of usage

Has anything changed or happened in those few days? Have Linux updates been applied? There are a lot of updates kicking around at the present time with some of them causing more problems than they fix.

It might also be helpful for us to see a log file for the guest that freezes. To quote the oracle that is Socratis...

• Start the VM from cold-boot (not from a paused or saved state) / Observe error / Shutdown the VM.
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response (see the "Upload attachment" tab below the reply form).

-Andy.

[foice]

thanks for these suggestions!

yes, I have got updates in recent times, both of VirtualBox and more recently OS updates. The latter seem to be more likely to be time-correlated with the freezes.

I understand that I have to wait for the freeze to happen again to produce these logs, correct? I am asking because when you say "Observe error/Shutdown VM" sounds like I should do a normal shutdown, but, of course, with a frozen machine I cannot do a normal shutdown. I normally try ACPI shutdown (and it never worked so far) and then go for "Reset" plain and simple. Will this give me meaningful logs?

[socratis]

Once it freezes, kill the VM. The whole idea is to *not* take the log while the VM window is still active. Also, please install Memory Monitor on your host. You're going to love it...

[foice]

it took more than usual, but it froze ... here is the log as requested (I had to zip it because of size limits in the upload)

[socratis]

I had to zip it because of size limits in the upload

Not because you were specifically told to do so?

Save only the first "VBox.log", ZIP it and attach it

00:00:09.159436 Host RAM: 16384MB (16.0GB) total, 4783MB (4.6GB) available
00:00:09.347136 RamSize <integer> = 0x00000001fa000000 (8 489 271 296, 8 096 MB, 7.9 GB)

Do you see the problem? You should... You are assigning memory to your guest, that you do not have available. Either close some applications on the host, buy more RAM for the host, or reduce the amount of RAM assigned to the guest.

BTW, I told you to download the Memory Monitor application, just for that reason. Let me take a wild guess... you either didn't or you didn't pay attention to it, right?

You need to pay more attention to the advice that we give you; either it's the "ZIP the log" or "pay attention to your available memory" if you want to keep on having a conversation.

[foice]

Dear socratis, thanks for the explanation of the crash. This is very helpful.

I am surprised this kind of issue can arise at all, but essentially what you are saying is that my host has to keep RAM memory for the VB, physical RAM memory. I am surprised the VirtualBox manager on the host does not take care of this by requesting the RAM for the virtual machine.

I will try to reduce my memory usage on both sides, i.e. reducing the memory allocated to the VB, and keeping low memory uage on the host.

Concerning your program, am I wrong that you link pointed to a page containing just a link to the DMG and absolutely no information whatsoever on what the program does, or looks like (not even a screen-shot) ... Given that, you might understand better why I have not even downloaded it

[socratis]

my host has to keep RAM memory for the VB, physical RAM memory. I am surprised the VirtualBox manager on the host does not take care of this by requesting the RAM for the virtual machine.

You bumped into a "feature" of VirtualBox. Here's how it roughly works. You tell VirtualBox that you need X RAM for your guest. VirtualBox does not allocate that memory from the beginning, it only allocates it as needed from the guest, in a scheme that's called "lazy memory allocation".

See the following discussion about the allocation for an OSX client (with 6 GB RAM) starting on my host (BTW, that *is* MemoryMonitor showing the memory allocation): viewtopic.php?f=7&t=77663#p362171

In the next post of the thread, Perryg points to a "switch" that you can set so that the guest memory is pre-allocated from the start. Keep on reading that thread for both the switch and the change in behavior.

As for the Memory Monitor, it's one of the apps that I install on every OSX that I get my hands on, next to the Activity Monitor (both in the Dock) and X Resource Graph. (tacked on the top-right side). It is as safe an app as they come. It's GPL and even includes the source code. I usually keep it in "~/Applications" and have it launch at startup.


PS. BTW, that thread that I pointed you to is titled "Reasons of vm to get into "aborted" state", just like what you're seeing. The actual switch is from Ramshankar's comment in the thread "Virtual box and memory management". I would suggest to read both threads...

[foice]

Thanks for pointing to this

Code: Select all

VBoxManage setextradata <vmname> VBoxInternal/RamPreAlloc 1

. I like to book resources upfront, so I did for the hard drive VDI file.

Concerning your tool, it is still not clear to me how it is different from looking at Activity Monitor or

Code: Select all

memory_pressure

command. Thanks for the explanations!

[socratis]

so I did for the hard drive VDI file.

You don't do it for the VDI, you do it for the VM. BTW, I hope that you read Ramshankar's warning about the VM starting slower with that setting...

As for the Memory Monitor, 1) it's not my application, I wish and 2) I find it a lot easier to take a quick look at the Dock, vs have a Terminal open. I won't even go to the Activity Monitor... It used to be much better, but after 10.7 or 10.8 they changed it and it now is basically a graph of a useless statistic; memory pressure (?!?).

[foice]

I have reduced to 4 Gb, and set it to allocate it at boot time (non-lazy). As you said, it started a bit slower, but nothing really terrible. Looking at Activity Monitor one can clearly see that ~4 Gb have been taken at the moment I started the virtual box.

Still it froze after 3h. I am looking at the log, also attached, and (also looking at the previous log) I do not really see any "warning" or "fatal error" or anything like that. Also, searching from ram in the texts I see nothing. How did you recognize in the previous log that the error was because of memory?

In any case, I have this command /usr/bin/memory_pressure, which gives the following, don't you have that?

Code: Select all

~>memory_pressure
The system has 2147483648 (524288 pages with a page size of 4096).

Stats:
Pages free: 22461
Pages purgeable: 69122
Pages purged: 45039220

Swap I/O:
Swapins: 115093016
Swapouts: 119559748

Page Q counts:
Pages active: 1008623
Pages inactive: 967477
Pages speculative: 7355
Pages throttled: 0
Pages wired down: 1831853

Compressor Stats:
Pages used by compressor: 355942
Pages decompressed: 132825765
Pages compressed: 192237608

File I/O:
Pageins: 94094222
Pageouts: 573235

System-wide memory free percentage: 47%

[socratis]

[quote="foice"]The system has 2147483648 (524288 pages with a page size of 4096).
Pages free: 22461[/quote]

That's 4% free memory. It should raise red flags, no?

As for the freezing in general, I don't know if it's the host, the guest or VirtualBox. I would take out of the picture any guest energy/power savings, disable any screen savers, etc.

Other than that, we're shooting in the dark with no clues or evidence in the logs...