qt5_probing.py makes xorg.bin run with high CPU usage, eating RAM
#1592
Comments
|
Thanks for reporting. Might be related to #1580 . Aryoda will reply soon. The problem with |
Yes.
Installer comes as full DVD and as netinstall that downloads as needed. If you only used one of these options, maybe the other works better? (No idea, just speculating). |
|
I have now set up a VirtualBox VM using these instructions and it went surprisingly smooth: https://techviewleo.com/install-opensuse-tumbleweed-on-virtualbox-vmware-workstation/ I have installed a fresh Tumbleweed 20231219 with
and installed BiT v1.4.1 via yast but could not reproduce the problem (with BiT root): When starting a backup via the BiT Qt GUI
Could you please provide me more details how to reproduce the problem, eg.
|
|
the "problem" is not when starting from GUI as that works fine. |
|
As ROOT |
|
I am running a cron job as root (created by BiT) without errors now for 30 minutes (executed every 5 minutes). Any more ideas what could be different in your setup? BTW: A temporary workaround would be to deactivate the BiT systray icon be "deleting" the |
|
no idea, but will test your sidestep and report. tks |
|
that worked "this time" for me. seems there exists no option to control this "plugin" ?? tks, will monitor and report any further failures. tks |
Unfortunately not, this is legacy work and the idea was to separately package plugins to install/uninstall them but every package I know delivers the systray icon plugin always together with the BiT (Qt5) GUI.
Most probably in Qt5 or the Qt5 wrapper in combination with the |
|
Could you please post the output of here. I want to check if a non-standard Qt5/KDE theme could cause the trouble for On my VM I get this output: |
|
I only have this problem with root from cron, never from the qt app as root or any occasion as . And do not have it on my server with: |
|
The GPU and other graphics info:
BiT is started for two backups, via anacron every 1 and 4 hours, set in the GUI.
Returns after every boot.
I have appended it below for better readability.
May also be of interest:
The only config is |
Ah! Does the anchron BiT job hang if it is started after a reboot but before the first user is logged in with a desktiop environment like KDE Plasma (establishing an Xorg session)? Anachron does directly start overdue jobs... This could also explain why the old implementation of checking for systray icon support using I am trying to test scenario this in my VM... Notes:
|
|
note that xdpyinfo does not appear to be present when my instance hangs. |
|
do not know what has changed but my root instance started by cron is again hanging: (lines will wrap): |
|
note, maybe because I renamed rather than deleting the systrayplugin. have now deleted them. |
renaming does not work, only moving into another folder or deleting it (since all *.py files in the plugin folder will be loaded in BiT) |
|
I could reproduce it by booting without logging in while a BiT root 100 % cpu and a few dozens of hanging processes: THX a lot for your very helpful Now I have to find a way to debug this without having a debugging GUI in my VM and simulating a started cron job... |
Strange. I rebooted to CLI, logged in as root and waited for ~15min. The only python processes were a backup-job after ~2min and later another. Seems legit; I have two backup profiles active. If you want me to provide additional info or do some tests, tell me soon. I plan to change to a LVM setup during the holidays and that may entail a fresh system setup (have not researched the procedure yet).
Save it somewhere; the structure is great for anything that needs checking at regular intervals. With a sound alarm ( |
|
I've made it into a login script: |
I can even provoke the problem by switching to a terminal in the login screen after booting (via Ctrl+Alt+F1 or Host-Key+F1 in my VM) and manually starting a backup with
I can reproduce the problem now and once I fix it it would be great if could test it again |
OK. See on the other side. :-) Oh-- and have great holidays! |
|
* paka ***@***.***> [02-01-24 13:40]:
* aryoda ***@***.***> [02-01-24 13:27]:
> @ptilopteri THX for checking the new version! Yes, I could not fix the problem for this release since I did not find a solution and since you are the only user so far reporting this after including a 30-secs timeout which for some reasons does not work in your case
>
> The current workaround is described in the [known issues](https://github.com/bit-team/backintime?tab=readme-ov-file#qt5_probingpy-may-hang-with-high-cpu-usage-when-running-bit-as-root-via-cron) (which totally disables the systray icon).
>
> I am considering two options:
> 1. Never start the systray icon as root (except in the GUI - but neither from CLI nor cron job)
> 2. Add an option to suppress the systray icon and add this option to root cron jobs (feels like too much work though)
>
> I would like to wait for more (other) user issues on this topic perhaps I can collect evidence then to find the root cause and a solution.
> Message ID: ***@***.***>
well, doesn't quite work the way you describe, at least for me.
stopped current root instance of backintime-qt
removed /usr/share/backintime/common/qt5_probing.py completely
and started a root cron job
systray icon appeared
and cron job completed.
systray icon disappeared
repeated with same result
and /usr/bin/dbus-launch.x11 appears but closes several seconds after
rsync finishes.
Message ID: ***@***.***>
rebooted and performed same sequence with same results
…--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
|
|
@ptilopteri My bad, I forgot to remove other code changes before testing the proposed workaround. Thanks a lot for reporting it here. I will prepare a patch file to disable the qt5 probing as root (even though the GUI will also be affected) but for now this will be the easiest workaround for you until I find a better solution. |
|
@ptilopteri I have prepared a workaround as patch for the hanging To apply it use
with the correct installation path of This effectively disables qt5_probing completely if run as root so you should never see a hanging |
|
* aryoda ***@***.***> [02-02-24 15:06]:
@ptilopteri I have prepared a workaround as patch for the hanging `qt5_probing.py` which works in my VM:
[1592_workaround.txt](https://github.com/bit-team/backintime/files/14144837/1592_workaround.txt)
To apply it use
`sudo patch -p1 /usr/share/backintime/common/qt5_probing.py < 1592_workaround.txt`
with the correct installation path of `backintime` (`which backintime`).
This effectively disables qt5_probing completely if run as root so you should never see a hanging `qt5_probing.py` (can be checked with `ps` which shows the path).
Message ID: ***@***.***>
that works for me but now there is no systemtrayicon. before applying
patch and with removing /usr/share/backintime/plugins/qt4plugin.py, was
working and systemtrayicon was functional. ??
but, there was a haning dbus-launch.x11
which caused X11 to consume CPU cycles.
tks
--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
|
THX a lot for testing and reporting the test results here! That is intentional since it is a workaround (better no systray icon instead of a hanging system)
This file should not be installed anymore since BiT v1.4.0 Since BiT v1.4.3 (release yesterday) |
|
* aryoda ***@***.***> [02-02-24 17:08]:
> that works for me but now there is no systemtrayicon.
THX a lot for testing and reporting the test results here!
That is intentional since it is a workaround (better no systray icon instead of a hanging system)
until I find a better solution.
> and with removing /usr/share/backintime/plugins/qt4plugin.py
This file should not be installed anymore since BiT v1.4.0
If it still existed it would explain why the system did hang no matter what changes were made to `qt5_probing.py`.
Since BiT v1.4.3 (release yesterday) `make install` does remove `qt4plugin.py` to avoid such left-over files.
Message ID: ***@***.***>
latest BiT build, c65fc91, is again hanging on
/usr/share/backintime/common/qt5_probing.py and will not progress until
/killing that process. root cron job.
I have added:
sleep 45 ;
kill -9 $(pidof /usr/bin/python3 /usr/share/backintime/common/qt5_probing.py) $(pidof dbus-launch.x11)
in order to successfully utilize BiT for root scheduled jobs.
…--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
|
Did you apply my patch after installing this build? Without that patch your system will hang for whatever reasons. As I mentioned here I am trying to find a solution that will show at least the systray icon for BiT (root) backups started via the GUI (but not by cron as root - this is simply not reliable anymore). Please give me some time for this... |
|
* aryoda ***@***.***> [02-07-24 20:00]:
> latest BiT build, [c65fc91](c65fc91), is again hanging on /usr/share/backintime/common/qt5_probing.py and will not progress until /killing that process. root cron job.
Did you apply [my patch](#1592 (comment)) after installing this build?
Without that patch your system will hang for whatever reasons.
As I mentioned [here](#1592 (comment)) I am trying to find a solution that will show at least the systray icon for BiT (root) backups started via the GUI (but not by cron as root - this is simply not reliable anymore).
Please give me some time for this...
--
Message ID: ***@***.***>
ok, applied yr patch to build c65fc91
…--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
|
|
* paka ***@***.***> [02-07-24 21:44]:
* aryoda ***@***.***> [02-07-24 20:00]:
> > latest BiT build, [c65fc91](c65fc91), is again hanging on /usr/share/backintime/common/qt5_probing.py and will not progress until /killing that process. root cron job.
>
> Did you apply [my patch](#1592 (comment)) after installing this build?
>
> Without that patch your system will hang for whatever reasons.
>
> As I mentioned [here](#1592 (comment)) I am trying to find a solution that will show at least the systray icon for BiT (root) backups started via the GUI (but not by cron as root - this is simply not reliable anymore).
>
> Please give me some time for this...
>
ok, applied yr patch to build c65fc91
Message ID: ***@***.***>
rebuild bit from git last night to 1.4.4-dev.6eb26beb
and /usr/share/backintime/common/qt5_probing.py is stil present. Isn't
that supposed to be removed?
…--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
|
No, it requires "just" a decent fix (subject to be found). All I can do now is ask for patience... |
|
* paka ***@***.***> [02-07-24 21:44]:
* aryoda ***@***.***> [02-07-24 20:00]:
> > latest BiT build, [c65fc91](c65fc91), is again hanging on /usr/share/backintime/common/qt5_probing.py and will not progress until /killing that process. root cron job.
>
> Did you apply [my patch](#1592 (comment)) after installing this build?
>
> Without that patch your system will hang for whatever reasons.
>
> As I mentioned [here](#1592 (comment)) I am trying to find a solution that will show at least the systray icon for BiT (root) backups started via the GUI (but not by cron as root - this is simply not reliable anymore).
>
> Please give me some time for this...
>
> --
> Message ID: ***@***.***>
ok, applied yr patch to build c65fc91
built 1.4.4-dev.5cbffdf5 today and your patch no longer takes. Is it not
anymore required?
tks
--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
|
What do you mean with "no longer takes"? Does patching fail or is the patch no longer required to avoid the high CPU usage? Some background: A few commits ago we migrated the |
|
* aryoda ***@***.***> [02-24-24 17:00]:
> built 1.4.4-dev.5cbffdf5 today and your patch no longer takes. Is it not anymore required?
What do you mean with "no longer takes"?
Does patching fail or or is the patch no longer required to avoid the high CPU usage?
Some background: A few commits ago we migrated the `dev` version of BiT from Qt5 to Qt6 (using the Python package `PyQt6`) which also required renaming the `qt5_probing.py` to `qt_probing.py` (so my above patch may not find the file anymore) but Qt6 may possibly also contain a fix for the problem.
Message ID: ***@***.***>
built 1.4.4-dev.5cbffdf5 and tried to apply the patch but the patch said
it was already applied ??? It was ?? applied during the build
automagically or ?? as I was unable to apply it:
sudo patch -p1 /usr/share/backintime/common/qt5_probing.py <
./1592_workaround.txt
patching file /usr/share/backintime/common/qt5_probing.py
Reversed (or previously applied) patch detected! Assume -R? [n]
so the patch has been committeed ?? or ????
and is no longer necessary?
…--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
|
|
* paka ***@***.***> [02-24-24 18:50]:
* aryoda ***@***.***> [02-24-24 17:00]:
> > built 1.4.4-dev.5cbffdf5 today and your patch no longer takes. Is it not anymore required?
>
> What do you mean with "no longer takes"?
>
> Does patching fail or or is the patch no longer required to avoid the high CPU usage?
>
> Some background: A few commits ago we migrated the `dev` version of BiT from Qt5 to Qt6 (using the Python package `PyQt6`) which also required renaming the `qt5_probing.py` to `qt_probing.py` (so my above patch may not find the file anymore) but Qt6 may possibly also contain a fix for the problem.
> Message ID: ***@***.***>
built 1.4.4-dev.5cbffdf5 and tried to apply the patch but the patch said
it was already applied ??? It was ?? applied during the build
automagically or ?? as I was unable to apply it:
sudo patch -p1 /usr/share/backintime/common/qt5_probing.py <
./1592_workaround.txt
patching file /usr/share/backintime/common/qt5_probing.py
Reversed (or previously applied) patch detected! Assume -R? [n]
so the patch has been committeed ?? or ????
and is no longer necessary?
Message ID: ***@***.***>
fwiw: I edited your provided patch, s/qt5_/q5_/ and it applied correctly
and am testing the build.
And it completed successfully.
note: instructions to "rm /usr/share/backintime/common/qt5_probing.py" on
github should be revised.
tks
…--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
|
|
TODO: Check if this kernel change may be reason the for the blocking
We are "hijacking" the X11 files of the user 1000 when running as root "just" to show the systray icon:
It looks like the kernel patch may strike here... |
It looks like the same problem is at work in #1716. |
When backintime runs its
qt5_probing.py,xorg.binconsumes a full CPU (~97..~102%). This happens only with the/usr/bin/python3 /usr/share/backintime/common/qt5_probing.pyprocesses. Quickly after they are killed,xorg.binis back to normal.Also RAM and swap fill up. If I don't kill the
qt5_probing.pyin time, the machine becomes unresponsive (and hot, duh).Maybe related: their CPU loads are high themselves.
Before killing:
The processes were killed with:
About a minute after after killing
xorg.binis at <1% CPU load.The backup jobs have finished (one rsync is still active), but earlier tests have shown that they not the culprits.
This happened with BiT version 1.4.1 both from YaST (SUSE packet manager), and directly from GitHub.
Python version is 3.11.6.
Operating System: openSUSE Tumbleweed 20231215
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11
Kernel Version: 6.6.3-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Wellllll..... Could that have a common cause?
The text was updated successfully, but these errors were encountered: