Qubes extremely slow due to numerous qubes.GetDate tasks created

Since yesterday, my Qubes installation has become quite useless, possibly due to an update:

Soon after booting, dom0 creates tasks performing the qubes.GetDate function. These tasks are created in a loop until all resources are exhausted, which takes about a minute when several thousand of these tasks have been created. According to the display of the top command in dom0, all these tasks are in the state of sleeping. Most of the time, this effect starts as soon as the first VM is started. It does not depend on the type of the VM (TemplateVM, AppVM or SeviceVM), and not on the template used (Fedora or Debian).

The system is running Qubes R4.1.2 for several months, using kernel-latest (6.3.9), but the effect occurs even with older kernels. Apart from the German language pack and the Gedit editor, no other software is installed in dom0.

I would appreciate it very much if anyone could tell me if they have observed a similar behavior and possibly even found a cause for this.

Is system suspend involved?
Anyway, there is core-admin v4.1.32 (r4.1) · Issue #3849 · QubesOS/updates-status · GitHub in current-testing repo which may help here.

Suspend is not involved here - the system keeps just running.

I’ll have a look into core-admin.

I am running qubes-core-admin-client version 4.1.31 - if that helps.

what about qubes-core-dom0?

Also version 4.1.31-1

Some additional observations:

  • If Qubes is started without any VM being started on booting, the superfluous tasks do not appear immediately. I started a backup job to a local disk, and these tasks appeared after some 20 minutes, slowing the system down.

  • After about an hour, these tasks had disappeared again.

  • Starting sys-usb at that time, started the tasks immediately again.

  • So far, I tested under XFCE. Repeating the tests under KDE had the same results. So, this fault is independent of the desktop environment.

  • After logging out and in again, the tasks remained and kept multiplying.

journalctl shows each of these tasks to start the script /etc/qubes-rpc/qubes.GetDate. Renaming this script to something else seems to stop the whole business. But I wonder what the cause may be and what the are the consequences of renaming this script.

Perhaps qubes time sync will stop functioning. Not quite serious.

The error seems to be caused by setting dom0’s clockvm to dom0. In this case, the script /etc/qubes-rpc/qubes.GetDate seems to have gone into an infinite loop, possibly due to a race condition. Setting the clockvm to sys-net solved the issue. (I have no idea what caused the erroneous setting.)

In the meantime, I changed qubes-core-dom0 to version 4.1.32, but this had no effect: the loop occurs there, too, if and only if dom0’s clockvm is set to dom0.


I’m never sure if you can mark your own post as the solution, so I did it. Thank you for the explanation @GWeck, that was an intriguing issue for me! Of course feel free to correct if you think marking the post as the solution wasn’t right!

1 Like