Whonixcheckdaemon locks up system without X

Hi. Hope this is a reasonable place to report this.

Just recently installed 10.0.0.5.5. I’m running Gateway with 128 MB, cause I don’t need a GUI. Started losing Tor occasionally. After some investigation, I found out that when whonixcheckdaemon is preparing to run the daily whonixcheck and is issuing it’s message about in however many seconds it will run whonixcheck, the progress bar updates are creating msgprogress processes that never die and eventually make parts of the system unresponsive. This only seems to happen if X is not running.

I can save the system if I kill whonixcheckdaemon and the offending msgprogress processes within 10 or 15 seconds, and then I can run whonixcheck manually, but it’d be nice to have a permanent fix.

Here’s what top shows after a few seconds:

[code]top - 08:50:20 up 5 min, 3 users, load average: 0.63, 0.40, 0.21
Tasks: 214 total, 1 running, 213 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.2 us, 10.3 sy, 0.0 ni, 0.0 id, 80.9 wa, 0.0 hi, 0.6 si, 0.0 st
KiB Mem: 124532 total, 111316 used, 13216 free, 728 buffers
KiB Swap: 522236 total, 0 used, 522236 free, 13144 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18 root 20 0 0 0 0 S 2.3 0.0 0:00.16 kswapd0
10866 root 20 0 13384 5132 876 D 1.1 4.1 0:01.89 iotop
2177 root 20 0 2412 796 132 S 0.3 0.6 0:00.19 haveged
10743 user 20 0 5604 2000 672 S 0.3 1.6 0:00.10 bash
12435 user 20 0 4972 1368 672 S 0.3 1.1 0:00.03 msgprogress
12800 user 20 0 4532 788 352 R 0.3 0.6 0:00.12 top
13310 user 20 0 4892 1288 672 S 0.3 1.0 0:00.02 msgprogress
13697 user 20 0 4872 1276 672 S 0.3 1.0 0:00.02 msgprogress
14180 user 20 0 4828 1216 672 S 0.3 1.0 0:00.02 msgprogress
14348 user 20 0 4816 1200 672 S 0.3 1.0 0:00.01 msgprogress
14600 user 20 0 4800 1196 672 S 0.3 1.0 0:00.02 msgprogress
15124 user 20 0 4764 1144 672 S 0.3 0.9 0:00.01 msgprogress
15212 user 20 0 4752 1132 672 S 0.3 0.9 0:00.01 msgprogress
15518 user 20 0 4740 1116 672 S 0.3 0.9 0:00.01 msgprogress
16179 user 20 0 4720 1096 672 S 0.3 0.9 0:00.01 msgprogress
16552 user 20 0 4696 1080 672 S 0.3 0.9 0:00.01 msgprogress
1 root 20 0 2200 384 280 S 0.0 0.3 0:00.62 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.10 ksoftirqd/0[/code]

And iotop:

Total DISK READ: 364.39 K/s | Total DISK WRITE: 0.00 B/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 18 be/4 root 0.00 B/s 0.00 B/s 0.00 % 97.13 % [kswapd0] 1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init [2] 2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd] 3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0] 6 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0] 7 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0] 8 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuset] 9 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khelper]
(But VBox doesn’t show disk access.)

I also have a screenshot after the point of no return, showing a kernel message about jbd2. Let me know if you need to see that, as well as any other info that will help. Thanks.

Confirmed. No more input required for now.

Increasing RAM to 196 MB works as a workaround.

This is an issue in msgcollector.

Will be fixed in Whonix 11.

Please test if you can.

Testers Wanted! Whonix 11 ( 11.0.0.2.3 )