13+ Gigs of logs in dom0 for 1 VM

a appVM running Open Broadcaster and Xephyr filled the dom0 drive with 13+ Gigs of logs in /var/log/qubes/guid.quobename.log .
A sample:

shmimage for 0x740022b(remote 0x2200006), x: 381, y: 581, w: 296, h: 16
  do_shm_update for 0x740022b(remote 0x2200006), after border calc: x=381, y=581, w=296, h=16
shmimage for 0x740022b(remote 0x2200006), x: 381, y: 648, w: 296, h: 16
  do_shm_update for 0x740022b(remote 0x2200006), after border calc: x=381, y=648, w=296, h=16
shmimage for 0x740022b(remote 0x2200006), x: 0, y: 22, w: 1079, h: 482
  do_shm_update for 0x740022b(remote 0x2200006), after border calc: x=0, y=22, w=1079, h=482
shmimage for 0x740022b(remote 0x2200006), x: 381, y: 581, w: 296, h: 16
  do_shm_update for 0x740022b(remote 0x2200006), after border calc: x=381, y=581, w=296, h=16
shmimage for 0x740022b(remote 0x2200006), x: 381, y: 648, w: 296, h: 16
  do_shm_update for 0x740022b(remote 0x2200006), after border calc: x=381, y=648, w=296, h=16

The next to biggest log is 320kB

Erasing the file then shutting down the appVM fixes the symptom. I’m posting this because other people may run into whatever the underlying issue is.

R4.0 or R4.1?

Also, I thought log rotation was already in place for both?

Under R4.0 large data to dom0 shouldn’t cause problems until the entire pool is full, but under R4.1 the default is 20GB and I’m not sure the auto extend works down to the filesystem level without a dom0 reboot.

That could cause serious issues.

B

r4.1

This log looks like a log with debug enabled (check “debug” property of the qube), normally this file is rather small. The log is rotated automatically when starting a qube.

1 Like

That was it, thanks.
I had enabled “debug mode” thinking that it would run in seamlessless mode (I.E. one big window with a desktop instead of seamless mode) if I did that for the linux appVM.
(I believe it does work that way for a windows appVM)