-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BIT hangs when starting a backup as root #1580
Comments
Thanks a lot for your detailed issue report! Q1: Are you using wayland or X11? Q2: Have you also installed the BiT GUI ( Q3: Could you please show me the output of
and
This is an isolated test of the python code that seems to block as root but not as normal user... Edit: The @buhtz |
Easy to reproduce on a fresh Suse Tumble... VM. Fixed via #1581 Note to @jim-moe : The bug was covered by a unit test. So I assume you have not run unit tests before packaging BIT for Suse. No offense. Even Debian/Ubuntu do not run the tests. We do work on an easier handling of the test suite, too. But until then I would suggest you to run the unit test manually on your own machine before finishing the packaging. |
wayland
BiT GUI is installed.
|
OK, I need to set up an OpenSuse VM to look deeper into the actual configuration that may cause problems.
How did you start the backup? Via BiT GUI, cmd line (manually) or scheduled ( |
gnome 45.2
Yes, quite reproducibly. Previously, it was |
Cron. |
Is there any kind of non-standard hardening enabled (beyond the standard installation)? |
No. |
I am running openSUSE Tumbleweed and have same problem with this action is recent but I cannot tell you when it began. backintime-qt-1.4.1-1.1.noarch but the hanging began prior to that. |
I am still having problems to set up a working VM with Tumbleweed and Gnome with vagrant (getting support for this) |
@jim-moe I have set up a VM now but could not reproduce the problem. For details see my post in another issue with the same problem: #1592 (comment) Could you please provide me more details on how to reproduce this problem (see linked post above)? THX :-) Edit: I am esp. interested if you are using |
…run as root and no user is logged into a desktop environment
…robing.py" hangs; Cannot launch BiT (root) on Wayland - "qt5_probing.py" hangs when BiT is run as root and no user is logged into a desktop environment - BiT (root) starter script does not set Qt5 wayland-egl plugin anymore but uses the default (like BiT userland) - Improve logging (all sub process do now use the log context "backintime" too for easy journalctl grepping
…robing.py" hangs; Cannot launch BiT (root) on Wayland - "qt5_probing.py" hangs when BiT is run as root and no user is logged into a desktop environment - BiT (root) starter script does not set Qt5 wayland-egl plugin anymore but uses the default (like BiT userland) - Improve logging (all sub processes do now use the log context "backintime" too for easy journalctl grepping
…h BiT (root) on Wayland * "qt5_probing.py" hangs when BiT is run as root and no user is logged into a desktop environment * BiT (root) starter script does not set Qt5 wayland-egl plugin anymore but uses the default (like BiT userland) * Different Wayland Qt plugin was used in BiT (root) vs. BiT user-space: Now no wayland is enforced anymore * Improve logging (all sub processes do now use the log context "backintime" too for easy journalctl filtering via the ) Was PR #1597
Closed with PR #1597 |
BackInTime v1.4.1 (from opensuse OSS main repo)
Opensuse tumbleweed v20231130
linux 6.6.3-1-default x86_64
python 3.11.6
rsync version 3.2.7 protocol version 31
BIT hangs when starting a backup as user root. This is not a problem for non-privileged users.
It is similar to the issue with
xdpyinfo
; I could bypass that by killing thexdpyinfo
instance.The hang occurs here, shown by ps. When this process is killed, BIT proceeds to backup.
root 31136 35.7 0.0 190892 26960 ? SNl 09:00 19:36 \_ /usr/bin/python3 /usr/share/backintime/common/qt5_probing.py
There was nothing unusual in the system journal. There was nothing noted in
takesnashpot_.log
.The text was updated successfully, but these errors were encountered: