Open noyannus opened 8 months ago
What is the output of this snippet (should be True
otherwise the file is corrupt)?
cd /usr/share/backintime/common
python3 -c "import sys; sys.path.insert(0, '/usr/share/backintime/plugins/'); import systrayiconplugin; p = systrayiconplugin.SysTrayIconPlugin(); import snapshots; s = snapshots.Snapshots(); print(p.init(s))"
FYI: I have pushed a draft fix for the hanging processes (will test it in different scenarios the next days): https://github.com/aryoda/backintime/commit/b84568c7f20f1b71bcd72bc1d3c654c5dcd1c060
output of snippet is "True"
Mind if I unsubscribe now? I feel there is little I can add at this point, and it's cluttering my inbox.
A good and successful 2024 to you all.
Mind if I unsubscribe now? I feel there is little I can add at this point, and it's cluttering my inbox.
Please let me know if you find out how to do it. To my experience unsubscribing won't make an effect because you opened the Issue. Microsoft GitHub will bother you with your own issue no matter if you are subscribed or not.
A good and successful 2024 to you all.
To you, too. Thanks for reporting.
The 'unsubscribe' link in the email led to this reaction:
We shall see if they keep their word.
Thanks for reporting.
The gratitude is on my side -- it is people like you who provide quality software that everybody can afford.
output of snippet is "True"
OK, I have no clue and need the improved logging output of my upcoming PR. I suggest to wait until my bug fix is merged, test it with this version and then open a new issue if the systray icon does still not work. That way we keep the issues separated.
I know not why but after reinstalling backintime and backintime-qt and removing systrayiconplugin.py, the timed start of backintime by
I know not why but after reinstalling backintime and backintime-qt and removing systrayiconplugin.py, the timed start of backintime by via cron no longer works. The instance is there, pid, but just sits idle. GUI still works fine.
After fixing the systray icon bug I discovered that the subsequent user session DBus call of BiT did block too for root when no user is logged in. I have added a description of this "shadowed" bug to the "how to fix this bug" section in my above bug analysis
Why it sometimes works and sometimes not is still unclear to me and more tests are in my TODO list (esp. if the same happens on other distros).
You could try to replace the installed /usr/share/backintime/common/tools.py
(rename it to *.bak) with my fixed file that you can download here (... > View File > Download raw file):
If this doesn't work please
--debug
to the the BiT cron job(s) (via sudo crontab -e
)journalctl --since "30 minutes ago" | grep -i backintime
here so that I can check the Edit: I forgot to ask: From which source did you re-install BiT? OpenSuse repo, from source code here or from my cloned repo with the fixed code?
I know not why but after reinstalling backintime and backintime-qt and removing systrayiconplugin.py, the timed start of backintime by via cron no longer works. The instance is there, pid, but just sits idle. GUI still works fine.
After fixing the systray icon bug I discovered that the subsequent user session DBus call of BiT did block too for root when no user is logged in. I have added a description of this "shadowed" bug to the "how to fix this bug" section in my above bug analysis
Why it sometimes works and sometimes not is still unclear to me and more tests are in my TODO list (esp. if the same happens on other distros).
You could try to replace the installed
/usr/share/backintime/common/tools.py
(rename it to *.bak) with my fixed file that you can download here (... > View File > Download raw file):aryoda@b84568c#diff-aefcaf4a21864b54ca4e7ccb0febb72a9400694db77381e505cc23433f1bb729
replaced "tools.py" with your code and set
completed successfully.
tks,
I am unable to open a new issue and this one is prematurely closed. So here is the problem and relevant information:
To help us diagnose the problem quickly, please provide the output of the console command backintime --diagnostics
.
# backintime --diagnostics
Traceback (most recent call last):
File "/usr/share/backintime/common/backintime.py", line 1190, in <module>
startApp()
File "/usr/share/backintime/common/backintime.py", line 507, in startApp
args = argParse(None)
^^^^^^^^^^^^^^
File "/usr/share/backintime/common/backintime.py", line 568, in argParse
args, unknownArgs = mainParser.parse_known_args(args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/argparse.py", line 1902, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/argparse.py", line 2114, in _parse_known_args
start_index = consume_optional(start_index)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/argparse.py", line 2054, in consume_optional
take_action(action, args, option_string)
File "/usr/lib64/python3.11/argparse.py", line 1978, in take_action
action(self, namespace, argument_values, option_string)
File "/usr/share/backintime/common/backintime.py", line 742, in __call__
diagnostics = collect_diagnostics()
^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/backintime/common/diagnostics.py", line 74, in collect_diagnostics
'OS': _get_os_release()
^^^^^^^^^^^^^^^^^
File "/usr/share/backintime/common/diagnostics.py", line 398, in _get_os_release
return osrelease['os-release']
~~~~~~~~~^^^^^^^^^^^^^^
KeyError: 'os-release'
"os-release" is :
NAME="openSUSE Tumbleweed"
# VERSION="20240117"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20240117"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20240117"
BUG_REPORT_URL="https://bugzilla.opensuse.org"
SUPPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"
Additionally, please specify as precisely as you can the package or installation source where you got Back In Time from. Sometimes there are multiple alternatives, like in for Arch-based distros.
http://cdn.opensuse.org/tumbleweed/repo/oss
Additionally, please specify as precisely as you can the package or installation source where you got Back In Time from. Sometimes there are multiple alternatives, like in for Arch-based distros.
rpm -qi backintime
Name : backintime
Version : 1.4.1
Release : 2.1
Architecture: noarch
Install Date: Fri 19 Jan 2024 09:11:03 AM EST
Group : Productivity/Archiving/Backup
Size : 809796
License : GPL-2.0-or-later
Signature : RSA/SHA512, Wed 17 Jan 2024 04:24:42 PM EST, Key ID 35a2f86e29b700a4
Source RPM : backintime-1.4.1-2.1.src.rpm
Build Date : Wed 17 Jan 2024 04:24:21 PM EST
Build Host : i02-ch2d
Packager : https://bugs.opensuse.org
Vendor : openSUSE
URL : https://github.com/bit-team/backintime
Summary : Backup tool for Linux inspired by the "flyback project"
With "/usr/share/backintime/plugins/pycache/systrayiconplugin.cpython-311.pyc" present, backintime started as root from cron fails as it fails to start the systrayiconplugin.
this was advised solved in #1592 and marked closed based on next issue of backintime solved the problem. It has not.
but removing "/usr/share/backintime/plugins/pycache/systrayiconplugin.cpython-311.pyc" does again allow backintime to function from cron as root and does place the icon in the systray.
I am unable to add a title, I cannot type within the box?
please reopen or start a new issue
I am unable to open a new issue
That interests me. Why? What have you tried and what are the errors? Did Microsoft banned you some how?
backintime --diagnostics
Traceback (most recent call last): File "/usr/share/backintime/common/diagnostics.py", line 398, in _get_os_release return osrelease['os-release']
KeyError: 'os-release' ```
This indicates to me that you do not use the latest upstream (developer) version but only the latest release. That "os-release" error is fixed but not yet released. This seems to be the same with the qt-probing fix. It is fixed but not yet released.
Please try the latest development version (instructions) installed from this Microsoft GitHub repo. Or please wait until 1.4.2 is released.
I am unable to open a new issue
That interests me. Why? What have you tried and what are the errors? Did Microsoft banned you some how?
opened "new issue" and was unable to type within the "title" box
added data to "description" box successfully (followed directions).
unable to commit, labeled icon would not respond.
backintime --diagnostics
Traceback (most recent call last): File "/usr/share/backintime/common/diagnostics.py", line 398, in _get_os_release return osrelease['os-release']
KeyError: 'os-release' ```
This indicates to me that you do not use the latest upstream (developer) version but only the latest release. That "os-release" error is fixed but not yet released. This seems to be the same with the qt-probing fix. It is fixed but not yet released.
Please try the latest development version (instructions installed from this Microsoft GitHub repo. Or please wait until 1.4.2 is released. Message ID: @.***>
you are correct, updated version is 1.4.1-2.1
sorry for noise, attempting to build git version.
-- (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
- buhtz @.***> [01-19-24 09:56]:
I am unable to open a new issue
That interests me. Why? What have you tried and what are the errors? Did Microsoft banned you some how?
opened "new issue" and was unable to type within the "title" box
added data to "description" box successfully (followed directions).
unable to commit, labeled icon would not respond.
backintime --diagnostics
Traceback (most recent call last): File "/usr/share/backintime/common/diagnostics.py", line 398, in _get_os_release return osrelease['os-release']
KeyError: 'os-release' ```
This indicates to me that you do not use the latest upstream (developer) version but only the latest release. That "os-release" error is fixed but not yet released. This seems to be the same with the qt-probing fix. It is fixed but not yet released.
Please try the latest development version (instructions installed from this Microsoft GitHub repo. Or please wait until 1.4.2 is released. Message ID: @.***>
you are correct, updated version is 1.4.1-2.1
sorry for noise, attempting to build git version.
Message ID: @.***>
ps: successfully built backintime(qt) and issued root cron job also successfully.
tks for your attention and work.
-- (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 I am not sure if you still have the issue with the fixed version of BiT (must be built and installed by yourself from our dev
branch currently until we provide a new release). The distro packages are definitely not fixed until we provide our release (scheduled for end of January).
If your are still having problems with the dev
version I will re-open the issue (I assumed it as "fixed" after testing and closed it prematurely I have to admit)...
@ptilopteri I am not sure if you still have the issue with the fixed version of BiT (must be built and installed by yourself from our
dev
branch currently until we provide a new release). The distro packages are definitely not fixed until we provide our release (scheduled for end of January).If your are still having problems with the
dev
version I will re-open the issue (I assumed it as "fixed" after testing and closed it prematurely I have to admit)...
Message ID: @.***>
the "dev"/"fixed" version appears to be working for me. will advise in the next few days if I see any difficulties/anomalies.
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
- aryoda @.***> [01-19-24 12:43]:
@ptilopteri I am not sure if you still have the issue with the fixed version of BiT (must be built and installed by yourself from our
dev
branch currently until we provide a new release). The distro packages are definitely not fixed until we provide our release (scheduled for end of January).If your are still having problems with the
dev
version I will re-open the issue (I assumed it as "fixed" after testing and closed it prematurely I have to admit)...Message ID: @.***>
the "dev"/"fixed" version appears to be working for me. will advise in the next few days if I see any difficulties/anomalies.
root cron job hung again this am waiting for "backintime/common/qt5_probing.py" to complete.
sudo kill -9
-- (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 I have re-opend the issue.
Could you please
backintime --diagnostics
or at least backintime --version
--debug
to the BiT profile used for the root cron job (in Manage profiles > Expert Options > Paste additional options to rsync)sudo crontab -e
and add --debug
to the backintime job entries (move cursur after backintime
and insert --debug
- this is vi
so press i
to enter the edit mode, after editting press ESC
then :wq
to save the changes...qt5_probing.py
hangs and show me the output of sudo journalctl --since "YYYY-MM-DD hh:mm" | grep -i backintime
which YYYY-MM-DD hh:mm set to the date and time when cron started the scheduled job.@ptilopteri I have re-opend the issue.
Could you please
- provide me the output of
backintime --diagnostics
- add
--debug
to the BiT profile used for the root cron job (in Manage profiles > Expert Options > Paste additional options to rsync)- provoke the hanging
qt5_probing.py
via the root cron job and show me the output ofsudo journalctl --since "YYYY-MM-DD hh:mm" | grep -i backintime
which YYYY-MM-DD hh:mm set to the date and time when cron started the scheduled job.- give me some background (mainly: Was a user logged in when the cron job started; any special setup? ...)
Message ID: @.***>
openSUSE Tumbleweed
backintime --diagnostics
Traceback (most recent call last):
File "/usr/share/backintime/common/backintime.py", line 1190, in
KeyError: 'os-release'
os-release:
NAME="openSUSE Tumbleweed"
# VERSION="20240118"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20240118"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20240118"
BUG_REPORT_URL="https://bugzilla.opensuse.org"
SUPPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"
added "--debug"
there is a <user> logged in
no special setup
cron job:
/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7
//data/build/backintime_repos/usr/bin/backintime --profile-id 2
//backup-job >/dev/null
as set by backintime using your development version I compiled.
after 8 minutes, journalctl provides no data
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 9399 0.0 0.0 32108 17124 ? SN 19:17 0:00 \_
python3 -Es
/data/build/backintime_repos/usr/share/backintime/common/backintime.py
/--profile-id 2 backup-job
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 9400 0.0 0.1 178260 36960 ? SNl 19:17 0:00 \_
/usr/bin/python3
//data/build/backintime_repos/usr/share/backintime/common/qt5_probing.py
there is no icon visible in tray (or hidden from tray display)
I can kill 9400 and backintime will continue
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
- aryoda @.> [01-20-24 18:22]: @ptilopteri I have re-opend the issue. Could you please - provide me the output of
backintime --diagnostics
- add--debug
to the BiT profile used for the root cron job (in Manage profiles > Expert Options > Paste additional options to rsync) - provoke the hangingqt5_probing.py
via the root cron job and show me the output ofsudo journalctl --since "YYYY-MM-DD hh:mm" | grep -i backintime
which YYYY-MM-DD hh:mm set to the date and time when cron started the scheduled job. - give me some background (mainly: Was a user logged in when the cron job started; any special setup? ...) Message ID: @.> openSUSE Tumbleweed backintime --diagnostics # backintime --diagnostics Traceback (most recent call last): File "/usr/share/backintime/common/backintime.py", line 1190, instartApp() File "/usr/share/backintime/common/backintime.py", line 507, in startApp args = argParse(None) ^^^^^^^^^^^^^^ File "/usr/share/backintime/common/backintime.py", line 568, in argParse args, unknownArgs = mainParser.parse_known_args(args)
It looks like your installation does not contain the fix(es).
Can you please double check that you have installed our most-recent dev
version from Github correctly since this --diagnostics
bug was already fixed one month ago.
An indicative check you could use is backintime --version
which should show 1.4.2-dev
(unless you have already installed the dev
version a few weeks ago - then the version number is them same but it is not the most-recent dev
version - please reinstall then using these instructions (and don't forget to update your clone withgit pull
).
- aryoda @.> [01-20-24 18:22]: @ptilopteri I have re-opend the issue. Could you please - provide me the output of
backintime --diagnostics
- add--debug
to the BiT profile used for the root cron job (in Manage profiles > Expert Options > Paste additional options to rsync) - provoke the hangingqt5_probing.py
via the root cron job and show me the output ofsudo journalctl --since "YYYY-MM-DD hh:mm" | grep -i backintime
which YYYY-MM-DD hh:mm set to the date and time when cron started the scheduled job. - give me some background (mainly: Was a user logged in when the cron job started; any special setup? ...) Message ID: @.> openSUSE Tumbleweed backintime --diagnostics # backintime --diagnostics Traceback (most recent call last): File "/usr/share/backintime/common/backintime.py", line 1190, instartApp() File "/usr/share/backintime/common/backintime.py", line 507, in startApp args = argParse(None) ^^^^^^^^^^^^^^ File "/usr/share/backintime/common/backintime.py", line 568, in argParse args, unknownArgs = mainParser.parse_known_args(args) It looks like your installation does not contain the fix(es).
Can you please double check that you have installed our most-recent
dev
version from Github correctly since this--diagnostics
bug was already fixed one month ago.An indicative check you could use
backintime --version
which should show1.4.2-dev
(unless you have already installed thedev
version a few weeks ago - then the version number is them same but it is not the most-recent dev version - please reinstall then using these instructions (and don't forget to update your clone withgit pull
).
Message ID: @.***>
from my build per your instructions backintime 1.4.2-dev
and that is the instance I used in cron as root.
looks like I used wrong instance for "--diagnostics", below
{ "backintime": { "name": "Back In Time", "version": "1.4.2-dev", "latest-config-version": 6, "local-config-file": "/home/UsernameReplaced/.config/backintime/config", "local-config-file-found": true, "global-config-file": "/etc/backintime/config", "global-config-file-found": false, "started-from": "/data/build/backintime_repos/usr/share/backintime/common", "running-as-root": false, "user-callback": "/home/UsernameReplaced/.config/backintime/user-callback", "keyring-supported": true }, "host-setup": { "platform": "Linux-6.6.10-1-default-x86_64-with-glibc2.38", "system": "Linux #1 SMP PREEMPT_DYNAMIC Mon Jan 8 08:58:39 UTC 2024 (e04388e)", "OS": "openSUSE Tumbleweed", "display-system": "x11", "locale": "en_US, UTF-8", "PATH": "/home/UsernameReplaced/bin:/usr/local/bin:/usr/local/sbin:/usr/local/sbin:/usr/local/sbin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/sbin:/usr/sbin:/usr/sbin:/bin:/sbin:/sbin:/sbin:/sbin", "RSYNC_OLD_ARGS": "(not set)", "RSYNC_PROTECT_ARGS": "(not set)" }, "python-setup": { "python": "3.11.7 main Dec 15 2023 10:49:17 CPython GCC", "python-executable": "/usr/bin/python3", "python-executable-symlink": true, "python-executable-resolved": "/usr/bin/python3.11", "sys.path": [ "/data/build/backintime_repos/usr/share/backintime/qt/plugins", "/data/build/backintime_repos/usr/share/backintime/common/plugins", "/data/build/backintime_repos/usr/share/backintime/plugins", "/data/build/backintime_repos/usr/share/backintime/common", "/usr/lib64/python311.zip", "/usr/lib64/python3.11", "/usr/lib64/python3.11/lib-dynload", "/usr/lib64/python3.11/site-packages", "/usr/lib64/python3.11/site-packages/PIL", "/usr/lib64/python3.11/_import_failed", "/usr/lib/python3.11/site-packages" ], "qt": { "Version": "PyQt 5.15.10 / Qt 5.15.12", "Theme": "breeze", "Theme Search Paths": [ "/home/UsernameReplaced/.local/share/icons", "/var/lib/flatpak/exports/share/icons", "/usr/share/icons", ":/icons" ], "Fallback Theme": "breeze", "Fallback Search Paths": [] } }, "external-programs": { "rsync": { "version": "3.2.7", "protocol": "31.0", "capabilities": { "file_bits": 64, "inum_bits": 64, "timestamp_bits": 64, "long_int_bits": 64, "socketpairs": true, "symlinks": true, "symtimes": true, "hardlinks": true, "hardlink_specials": true, "hardlink_symlinks": true, "IPv6": true, "atimes": true, "batchfiles": true, "inplace": true, "append": true, "ACLs": true, "xattrs": true, "secluded_args": "optional", "iconv": true, "prealloc": true, "stop_at": true, "crtimes": false }, "optimizations": { "SIMD_roll": true, "asm_roll": false, "openssl_crypto": true, "asm_MD5": false }, "checksum_list": [ "xxh128", "xxh3", "xxh64", "md5", "md4", "sha1", "none" ], "compress_list": [ "zstd", "lz4", "zlibx", "zlib", "none" ], "daemon_auth_list": [ "sha512", "sha256", "sha1", "md5", "md4" ] }, "ssh": "OpenSSH_9.3p2, OpenSSL 3.1.4 24 Oct 2023", "sshfs": "3.7.4a", "encfs": "(no encfs)", "shell": "/bin/bash", "shell-version": "GNU bash, version 5.2.26(1)-release (x86_64-suse-linux)" } }
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
looks like I used wrong instance for "--diagnostics"
Does the cron
job hang in qt5_probing.py
on this instance with the most-recent BiT dev
version installed (then my fix would not always work)?
looks like I used wrong instance for "--diagnostics"
Does the
cron
job hang inqt5_probing.py
on this instance with the most-recent BiTdev
version installed (then my fix would not alway work)?Message ID: @.***>
will need to rebuild bit and system currently busy, will reply in about an hour. I don't know how up-to-date my build is, several days old.
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
- aryoda @.***> [01-21-24 11:42]:
looks like I used wrong instance for "--diagnostics"
Does the
cron
job hang inqt5_probing.py
on this instance with the most-recent BiTdev
version installed (then my fix would not alway work)?Message ID: @.> Message ID: @.>
ok, re-cloned and re-build bit/qt initiated root cron job, see tray icon now and did not hang on qt5_probing.py.
when finish will run again as previously the second job hung.
the second instance started correctly and displayed systray icon. did not hang.
and completed successfully
tks, the dev version appears to work correctly for me and root.
maybe re-close this issue :)
-- (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
the second instance started correctly and displayed systray icon. did not hang. and completed successfully tks, the dev version appears to work correctly for me and root.
Happy to hear that!
maybe re-close this issue :)
I will wait a few days to be absolutely sure.
The hanging cron jobs appeared normally only when no user is logged into a desktop environment and the cron job is running as root (best to be tested by rebooting and not logging into the DE).
Internal note as amendment to https://github.com/bit-team/backintime/issues/1592#issuecomment-1871524882:
Before closing this issue try if setting as described in connecting to user dbus as root) may also fix the problem and explains the reason for the missing authorization:
Use BusConnection instead of SessionBus and specify the address explicitly, combined with seteuid to gain access.
the second instance started correctly and displayed systray icon. did not hang. and completed successfully tks, the dev version appears to work correctly for me and root.
Happy to hear that!
maybe re-close this issue :)
I will wait a few days to be absolutely sure.
The hanging cron jobs appeared normally only when no user is logged into a desktop environment and the cron job is running as root (best to be tested by rebooting and not logging into the DE). Message ID: @.***>
unfortunately, the root cron job hung again this am. killing qt5_probing.py allowed it to continue
and completed successfully
-- (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
- aryoda @.***> [01-21-24 16:16]:
unfortunately, the root cron job hung again this am. killing qt5_probing.py allowed it to continue and completed successfully
Can you follow the steps 2 - 4 in https://github.com/bit-team/backintime/issues/1592#issuecomment-1902379764 to help me diagnose this?
Step 1 (diagnostics) is not required but backintime --version
to make sure that your installed dev
version was not overwritten by an older version in an overnight "update" of distro packages...
- aryoda @.***> [01-21-24 16:16]:
unfortunately, the root cron job hung again this am. killing qt5_probing.py allowed it to continue and completed successfully
Can you follow the steps 2 - 4 in https://github.com/bit-team/backintime/issues/1592#issuecomment-1902379764 to help me diagnose this?
qt5_probing.py appears to hang immediately journalctl provide no output
killing the qt5_probing.py instance returns email indicating start of a backintime process, but does not appear to continue, no instance of rsync is started.
Step 1 (diagnostics) is not required but
backintime --version
to make sure that your installeddev
version was not overwritten by an older version in an overnight "update" of distro packages...
backintime 1.4.2-dev, was built at noon my time -5 GMT
Message ID: @.***>
users reports: paka paka paka paka paka paka paka paka paka paka paka paka paka root
I do see an instance (or several) appears to start with the root cron job: /usr/bin/dbus-launch.x11 --autolaunch=3384cbc37a574dcc99445aa25cd2db04 /--binary-syntax --close-stderr
which puts on a load related to X
sudo kill -9 $(pidof dbus-launch.x11) stops dbus-launch.x11 and drops the load, but dbus-launch.x11 may restart several times requiring multiple following kill instances to stop it. and maybe this finally kills the BiT instance.
hope this helps
-- (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
qt5_probing.py appears to hang immediately journalctl provide no output
journalctl
as described in 3. of https://github.com/bit-team/backintime/issues/1592#issuecomment-1902379764 must provide some output if you have added --debug
(see 2. in the linked comment) before the root cron job hangs
and the --since
time and date is correct (= right before the execution time of the cron job that hangs)
Could you please check this again?
Just to be sure: You let BiT add the cron job - not by hand - this my be a different situation...
I do see an instance (or several) appears to start with the root cron job: /usr/bin/dbus-launch.x11 --autolaunch=3384cbc37a574dcc99445aa25cd2db04 /--binary-syntax --close-stderr which puts on a load related to X
Excellent observation, THX!
From https://stackoverflow.com/questions/71425861/connecting-to-user-dbus-as-root I know this is an permission issue and might be solved via setuid
to 1000
(first user) but this quite a hard-coded assumption that might not always work neither.
I tend to completely disable the systray icon for root cron jobs (but keep it in BiT root) since showing a systray icon from a root cron job by "hijacking" a user DBus and X11 session is not reliable (but a code legacy in BiT)...
qt5_probing.py appears to hang immediately journalctl provide no output
journalctl
as described in 3. of https://github.com/bit-team/backintime/issues/1592#issuecomment-1902379764 must provide some output if you have added--debug
(see 2. in the linked comment) before the root cron job hangs and the--since
time and date is correct (= right before the execution time of the cron job that hangs) Could you please check this again?
absolutely sure there was no output and the date:time was the time BiT was initiated. on the ensuing test, I will start journalctl search one minute prior to the cron job start time.
Just to be sure: You let BiT add the cron job - not by hand - this my be a different situation...
I will retest as I just duplicated an existing root cron job. which also makes it necessary to wait for the top of an hour as BiT only offers backups on :00 hours
I do see an instance (or several) appears to start with the root cron job: /usr/bin/dbus-launch.x11 --autolaunch=3384cbc37a574dcc99445aa25cd2db04 /--binary-syntax --close-stderr which puts on a load related to X
Excellent observation, THX!
From https://stackoverflow.com/questions/71425861/connecting-to-user-dbus-as-root I know this is an permission issue and might be solved via
setuid
to1000
(first user) but this quite a hard-coded assumption that might not always work neither.I tend to completely disable the systray icon for root cron jobs (but keep it in BiT root) since showing a systray icon from a root cron job by "hijacking" a user DBus and X11 session is not reliable (but a code legacy in BiT)...
Message ID: @.***>
killed qt5_probing.py @ 19:10
process did not continue, rsync faulted: notify-send Back In Time (root) : tumbleweed 'rsync' ended with exit code 1: See 'man rsync' for more details
output from journalctl: Jan 22 19:00:01 crash.wahoo.no-ip.org CRON[22771]: (root) CMD (/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 //data/build/backintime_repos/usr/bin/backintime --profile-id 2 backup-job >/dev/null) Jan 22 19:00:01 crash.wahoo.no-ip.org CRON[22769]: (root) CMDEND (/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 //data/build/backintime_repos/usr/bin/backintime --profile-id 2 backup-job >/dev/null) Jan 22 19:10:13 crash.wahoo.no-ip.org backintime[22788]: tumbleweed(2) :: INFO: Qt5 probing sub process killed after timeout without response Jan 22 19:10:13 crash.wahoo.no-ip.org backintime[22788]: tumbleweed(2) :: INFO: Lock Jan 22 19:10:13 crash.wahoo.no-ip.org backintime[22788]: tumbleweed(2) :: INFO: Take a new snapshot. Profile: 2 tumbleweed Jan 22 19:10:13 crash.wahoo.no-ip.org backintime[22788]: tumbleweed(2) :: INFO: Call rsync to take the snapshot Jan 22 19:10:13 crash.wahoo.no-ip.org backintime[22788]: tumbleweed(2) :: WARNING: Command "rsync --recursive --times --devices --specials --hard-links --human-readable -s --links --perms --executability --group --owner --info=progress2 --no-inc-recursive --debug --delete --delete-excluded -v -i --out-format=BACKINTIME: %i %n%L --link-dest=../../20240122-091641-258/backup --chmod=Du+wx --exclude=/data/BackInTimeTW --exclude=/root/.local/share/backintime --exclude=.local/share/backintime/mnt --include=/etc/ --include=/home/ --include=/opt/ --include=/usr/ --include=/home/paka/.config/darktable/ --include=/home/paka/.config/ --include=/home/paka/ --include=/mnt/nfs/ExT4/share/ --include=/mnt/nfs/ExT4/ --include=/mnt/nfs/ --include=/mnt/ --include=/root/ --exclude=.gvfs --exclude=.cache/ --exclude=.thumbnails --exclude=.local/share/[Tt]rash --exclude=.backup --exclude=~ --exclude=.dropbox --exclude=/proc/ --exclude=/sys/ --exclude=/dev/ --exclude=/run/ --exclude=/etc/mtab Jan 22 19:10:13 crash.wahoo.no-ip.org backintime[22788]: tumbleweed(2) :: WARNING: CONTINUE: --exclude=/var/cache/apt/archives/.deb --exclude=lost+found/ --exclude=/tmp/ --exclude=/var/tmp/ --exclude=/var/backups/ --exclude=.Private --exclude=/mnt/cifs --exclude=/home/paka/carol --exclude=/home/paka/cifs --exclude=/home/paka/sshfs --include=/etc/ --include=/home/ --include=/opt/ --include=/usr/ --include=/home/paka/.config/darktable/ --include=/mnt/nfs/ExT4/share/money.ods --include=/root/ --exclude=* / /data/BackInTimeTW/backintime/crash.wahoo.no-ip.org/root/2/new_snapshot/backup" returns 1
note that dbus-launch.x11 was again present but doesn't appear in journalctl.
-- (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
absolutely sure there was no output and the date:time was the time BiT was initiated. on the ensuing test, I will start journalctl search one minute prior to the cron job start time.
Perhaps this is a time zone issue...
Could you please give sudo journalctl -b SYSLOG_IDENTIFIER=backintime
a try after the cron job blocked and you have killed qt5_probing.py
...?
Meanwhile I am trying to configure my OpenSuse VM to reproduce this
process did not continue, rsync faulted: notify-send Back In Time (root) : tumbleweed 'rsync' ended with exit code 1: See 'man rsync' for more details
Please forgive me, I was totally stupid with my instructions to append --debug
and cause an rsync
error with that. Please instead do:
--debug
to the BiT profile used for the root cron job (in Manage profiles > Expert Options > Paste additional options to rsync)sudo crontab -e
and add --debug
to the backintime job entries (move cursor after backintime
and insert --debug
- this is vi
so press i
to enter the edit mode, after editting press ESC
then :wq
to save the changes...and remove the --debug
from Manage profiles > Expert Options > Paste additional options to rsync
@ptilopteri No need for actions on your side anymore - I can reproduce the hanging qt5_probing.py
in my VM when I do not log in at all after rebooting... Please give me some time to debug this...
@ptilopteri I have attached a patch to check if the user rights are in fact the problem on your setup (in my VM it did fix the hanging qt5_probing.py
).
You can apply the patch from the folder you have downloaded the patch file via:
sudo patch /usr/share/backintime/common/qt5_probing.py < 1592_qt5probing.txt
Note: Github does not allow to upload *.patch
files so it is a *.txt file ;-)
Could you please check if this fixes the problem (and does not cause others ;-) ? Thanks a lot!
PS: Please not that this will most-probably not be the final solution since it assumes that user id 1000 has an X11 display session; I just want to test if it works at all...
@ptilopteri I have attached a patch to check if the user rights are in fact the problem on your setup (in my VM it did fix the hanging
qt5_probing.py
.You can apply the patch from the folder you have downloaded the patch file via:
sudo patch /usr/share/backintime/common/qt5_probing.py < 1592_qt5probing.txt
Note: Github does not allow to upload
*.patch
files so it is a *.txt file ;-)Please not that this will most-probably not be the final solution since it assumes that user id 1000 has an X11 display session; I just want to test if it works at all... Message ID: @.***>
applied patch(txt) file ran root cron job qt5_probing.py still hangs with accompanying dbus-launch.x11 killing both instances allows root cron job to complete
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
applied patch(txt) file ran root cron job qt5_probing.py still hangs with accompanying dbus-launch.x11 killing both instances allows root cron job to complete
hm, either the patch does not work or it could not be applied completely...
Successful patching shows something like this on my machine:
> sudo patch /usr/share/backintime/common/qt5_probing.py < 1592_qt5probing.txt
patching file /usr/share/backintime/common/qt5_probing.py
Hunk #1 succeeded at 11 with fuzz 2 (offset 6 lines).
Hunk #2 succeeded at 114 with fuzz 2 (offset 22 lines).
I just saw in your logs that BiT seems to be installed in a different folder (not our default). I did not mention this but did you change the target folder of the patch to the location of the installed qt5_probing.py
? It should look then similar to this:
sudo patch //data/build/backintime_repos/usr/bin/backintime < 1592_qt5probing.txt
BTW: To undo the patch just run it again and answer the question with Y
es:
> sudo patch /usr/share/backintime/common/qt5_probing.py < 1592_qt5probing.txt
patching file /usr/share/backintime/common/qt5_probing.py
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n] y
Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines).
Hunk #2 succeeded at 94 (offset 2 lines).
applied patch(txt) file ran root cron job qt5_probing.py still hangs with accompanying dbus-launch.x11 killing both instances allows root cron job to complete
hm, either the patch does not work or it could not be applied completely...
Successful patching shows something like this on my machine:
> sudo patch /usr/share/backintime/common/qt5_probing.py < 1592_qt5probing.txt patching file /usr/share/backintime/common/qt5_probing.py Hunk #1 succeeded at 11 with fuzz 2 (offset 6 lines). Hunk #2 succeeded at 114 with fuzz 2 (offset 22 lines).
I just saw in your logs that BiT seems to be installed in a different folder (not our default). I did not mention this but did you change the target folder of the patch to the location of the installed
qt5_probing.py
? It should look then similar to this:
sudo patch //data/build/backintime_repos/usr/bin/backintime < 1592_qt5probing.txt
BTW: To undo the patch just run it again and answer the question with
Y
es:> sudo patch /usr/share/backintime/common/qt5_probing.py < 1592_qt5probing.txt patching file /usr/share/backintime/common/qt5_probing.py Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines). Hunk #2 succeeded at 94 (offset 2 lines).
yes, patch was applied but did not help afaics
but, keeping a root instance of bit-qt open allows root's cron bit instances to perform correctly. and there is no hanging "dbus-launch.x11" instance.
maybe that's a clue? but I have not seen a tray icon.
-- (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
but I have not seen a tray icon.
Not even when starting a backup from within root's BiT GUI?
but I have not seen a tray icon.
Not even when starting a backup from within root's BiT GUI?
-- Reply to this email directly or view it on GitHub: https://github.com/bit-team/backintime/issues/1592#issuecomment-1913176234 You are receiving this because you were mentioned.
Message ID: @.***>
no, running backup now from gui and no tray icon
-- (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
no, running backup now from gui and no tray icon
OK, I have tried to reproduce this in my VM with KDE Plasma but it I can see the BiT systray icon while taking a snapshot...
Could you please uninstall the patch and send me the output of
backintime-qt_polkit --debug
from a console while logged in as a user in your desktop environment and after starting one backup (take a snapshot)?
Perhaps I can find a clue in the logs...
You can remove or replace sensitive data in the log output...
@ptilopteri
no, running backup now from gui and no tray icon
OK, I have tried to reproduce this in my VM with KDE Plasma but it I can see the BiT systray icon while taking a snapshot...
- Which Desktop Environment are you using (Gnome, Xfce...?), any special window manager?
- Could you please uninstall the patch and send me the output of
sddm:kde5:plasma5
`backintime-qt_polkit --debug`
openSUSE is an rpm based system. to run BiT 1.4.2-dev requires I uninstall bit 1.4.1 and hand copy 1.4.2-dev files to appropriate locations, then reverse the action and reinstall BiT.
I will provide your requested information but need occasion to adjust system to use 1.4.2-dev
from a console while logged in as a user in your desktop environment and **after starting one backup (take a snapshot)**? Perhaps I can find a clue in the logs... You can remove or replace sensitive data in the log output...
-- Reply to this email directly or view it on GitHub: https://github.com/bit-team/backintime/issues/1592#issuecomment-1913287627 You are receiving this because you were mentioned.
Message ID: @.***>
fwiw: I am more interested in the backup performing correctly than seeing a system tray icon.
-- (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
- aryoda @.***> [01-27-24 13:40]:
@ptilopteri
no, running backup now from gui and no tray icon
OK, I have tried to reproduce this in my VM with KDE Plasma but it I can see the BiT systray icon while taking a snapshot...
- Which Desktop Environment are you using (Gnome, Xfce...?), any special window manager?
- Could you please uninstall the patch and send me the output of
sddm:kde5:plasma5
`backintime-qt_polkit --debug`
openSUSE is an rpm based system. to run BiT 1.4.2-dev requires I uninstall bit 1.4.1 and hand copy 1.4.2-dev files to appropriate locations, then reverse the action and reinstall BiT.
I will provide your requested information but need occasion to adjust system to use 1.4.2-dev
another thing, possibly part of problem, openSUSE Tumbleweed has no directory, "/usr/share/qt" but does have "/usr/share/qt5" and "/usr/share/qt6"
from a console while logged in as a user in your desktop environment and **after starting one backup (take a snapshot)**? Perhaps I can find a clue in the logs... You can remove or replace sensitive data in the log output...
-- Reply to this email directly or view it on GitHub: https://github.com/bit-team/backintime/issues/1592#issuecomment-1913287627 You are receiving this because you were mentioned.
Message ID: @.***>
fwiw: I am more interested in the backup performing correctly than seeing a system tray icon.
-- (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
-- Reply to this email directly or view it on GitHub: https://github.com/bit-team/backintime/issues/1592#issuecomment-1913341481 You are receiving this because you are subscribed to this thread.
Message ID: @.***>
-- (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
I will provide your requested information but need occasion to adjust system to use 1.4.2-dev
THX a lot in advance!
fwiw: I am more interested in the backup performing correctly than seeing a system tray icon.
I fully understand this and we already tried to pin down this problem with many Q&As. So I propose that after providing me above debug log we put this issue "on hold" so that you don't have to deliver more answers since I guess there is not much more you can do. I then have to find a setup to reproduce this myself. THX a lot for keeping your patience with me ;-)
I am already thinking of giving up launching the systray icons for root cron jobs since we misuse X11/Wayland and dbus here by hijacking user sessions as root. The future my possible see just a user systray icon that may be configured to "listen" to root BiT cron jobs too...
openSUSE Tumbleweed has no directory, "/usr/share/qt" but does have "/usr/share/qt5" and "/usr/share/qt6"
Yes, same on my Tumbleweed VM. I have just check our Makefiles but these folders are not used. Any files go into /usr/share/backintime/...
- aryoda @.***> [01-27-24 13:40]:
@ptilopteri
no, running backup now from gui and no tray icon
OK, I have tried to reproduce this in my VM with KDE Plasma but it I can see the BiT systray icon while taking a snapshot...
- Which Desktop Environment are you using (Gnome, Xfce...?), any special window manager?
- Could you please uninstall the patch and send me the output of
sddm:kde5:plasma5
`backintime-qt_polkit --debug`
openSUSE is an rpm based system. to run BiT 1.4.2-dev requires I uninstall bit 1.4.1 and hand copy 1.4.2-dev files to appropriate locations, then reverse the action and reinstall BiT.
I will provide your requested information but need occasion to adjust system to use 1.4.2-dev
Back In Time Version: 1.4.2-dev
Back In Time comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type `backintime --license' for details.
The application is already running! (pid: 31469)
DEBUG: [common/backintime.py:589 argParse] Arguments: {'debug': True} | unknownArgs: [] DEBUG: [common/configfile.py:591 Config.setCurrentProfile] Change current profile: 1=Main profile DEBUG: [common/tools.py:186 initiate_translation] No language code. Use systems current locale. DEBUG: [common/backintime.py:677 getConfig] config file: /root/.config/backintime/config DEBUG: [common/backintime.py:678 getConfig] share path: //root/.local/share/backintime DEBUG: [common/backintime.py:679 getConfig] profiles: 1=Main profile, 5=dent, 2=tumblewe
after killing BiT-qt
Back In Time Version: 1.4.2-dev
Back In Time comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type `backintime --license' for details.
DEBUG: [common/configfile.py:591 Config.setCurrentProfile] Change current profile: 1=Main profile DEBUG: [common/tools.py:186 initiate_translation] No language code. Use systems current locale. DEBUG: [common/backintime.py:677 getConfig] config file: /root/.config/backintime/config DEBUG: [common/backintime.py:678 getConfig] share path: /root/.local/share/backintime DEBUG: [common/backintime.py:679 getConfig] profiles: 1=Main profile, 5=dent, 2=tumbleweed DEBUG: [common/pluginmanager.py:245 PluginManager.load] Register plugin path /usr/share/backintime/plugins DEBUG: [common/pluginmanager.py:249 PluginManager.load] Probing plugin usercallbackplugin.py DEBUG: [common/pluginmanager.py:263 PluginManager.load] Add plugin usercallbackplugin.py DEBUG: [common/pluginmanager.py:249 PluginManager.load] Probing plugin systrayiconplugin.py DEBUG: [common/tools.py:735 is_Qt5_working] Qt5 probing result: exit code -6 DEBUG: [common/tools.py:738 is_Qt5_working] Qt5 probing stdout:
DEBUG: [common/tools.py:739 is_Qt5_working] Qt5 probing errout:
DEBUG: [common/qt5_probing.py:89
DEBUG: [plugins/systrayiconplugin.py:82 init] No system tray available to show the BiT system tray icon
DEBUG: [common/pluginmanager.py:249 PluginManager.load] Probing plugin notifyplugin.py
DEBUG: [common/pluginmanager.py:263 PluginManager.load] Add plugin notifyplugin.py
DEBUG: [plugins/usercallbackplugin.py:81 UserCallbackPlugin.callback] Call user-callback: /root/.config/backintime/user-callback 1 Main profile 5
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
DEBUG: [qt/qttools.py:229 createQApplication] QT QPA platform plugin: xcb
DEBUG: [qt/qttools.py:230 createQApplication] QT_QPA_PLATFORMTHEME=
from a console while logged in as a user in your desktop environment and **after starting one backup (take a snapshot)**? Perhaps I can find a clue in the logs... You can remove or replace sensitive data in the log output...
-- Reply to this email directly or view it on GitHub: https://github.com/bit-team/backintime/issues/1592#issuecomment-1913287627 You are receiving this because you were mentioned.
Message ID: @.***>
fwiw: I am more interested in the backup performing correctly than seeing a system tray icon.
-- (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
-- Reply to this email directly or view it on GitHub: https://github.com/bit-team/backintime/issues/1592#issuecomment-1913341481 You are receiving this because you are subscribed to this thread.
Message ID: @.***>
-- (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
I will provide your requested information but need occasion to adjust system to use 1.4.2-dev
THX a lot in advance!
fwiw: I am more interested in the backup performing correctly than seeing a system tray icon.
I fully understand this and we already tried to pin down this problem with many Q&As. So I propose that after providing me above debug log we put this issue "on hold" so that you don't have to deliver more answers since I guess there is not much more you can do. I then have to find a setup to reproduce this myself. THX a lot for keeping your patience with me ;-)
I am already thinking of giving up launching the systray icons for root cron jobs since we misuse X11/Wayland and dbus here by hijacking user sessions as root. The future my possible see just a user systray icon that may be configured to "listen" to root BiT cron jobs too...
openSUSE Tumbleweed has no directory, "/usr/share/qt" but does have "/usr/share/qt5" and "/usr/share/qt6"
Yes, same on my Tumbleweed VM. I have just check our Makefiles but these folders are not used. Any files go into /usr/share/backintime/...
well, I copied them directly to /usr/share/qt if BiT cannot find them there, tell me where to put them.
shame BiT cannot be configured for "make install" and "make uninstall". would make trouble shooting much easier and cleaner.
Message ID: @.***>
info you requested in another post
-- (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
well, I copied them directly to /usr/share/qt if BiT cannot find them there, tell me where to put them. shame BiT cannot be configured for "make install" and "make uninstall". would make trouble shooting much easier and cleaner.
Ah, I didn't mention this but you can build, install and even uninstall from the source following these instructions:
But it requires to install some more dev-relelated packages also documented in above link... Hint: If you install the BiT distro packages first and then overwrite them with the dev version most of the dependencies are already fulfilled.
This is the safest way to install BiT (CLI and GUI).
The target installation folder is then by default /usr/share/backintime
well, I copied them directly to /usr/share/qt if BiT cannot find them there, tell me where to put them. shame BiT cannot be configured for "make install" and "make uninstall". would make trouble shooting much easier and cleaner.
Ah, I didn't mention this but you can build, install and even uninstall from the source following these instructions:
But it requires to install some more dev-relelated packages also documented in above link...
This is the safest way to install BiT (CLI and GUI).
The target installation folder is then by default
/usr/share/backintime
Message ID: @.***>
note, when buiilding:
/////////////////////
Ran 11 tests in 0.436s
ImportError: Failed to import test module: test_diagnostics
Traceback (most recent call last):
File "/usr/lib64/python3.11/unittest/loader.py", line 162, in loadTestsFromName
module = import(module_name)
^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/backintime/common/test/test_diagnostics.py", line 4, in
Ran 1 test in 0.000s
FAILED (errors=1) make: *** [Makefile:568: unittest] Error 1
///////////////////
-- (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
When backintime runs its
qt5_probing.py
,xorg.bin
consumes a full CPU (~97..~102%). This happens only with the/usr/bin/python3 /usr/share/backintime/common/qt5_probing.py
processes. Quickly after they are killed,xorg.bin
is back to normal. Also RAM and swap fill up. If I don't kill theqt5_probing.py
in 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.bin
is 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?