Bugzilla – Bug 1197258
no more plasma after tumbleweed update
Last modified: 2022-03-23 09:36:44 UTC
Hi *, after updating to the before last Tumbleweed snapshot I lost my plasma GUI. After logging in via sddm I only get an empty desktop with a mouse cursor, that can be moved around. This is happening for all, even newly created accounts. The latest snapshot didn't cure this problem. plasmastart-x11 is running, but no kwin_x11 and no plasmashell. The system is unusable at the moment.
I am able to start everything manually from a tty: export DISPLAY=:0 export XAUTHLOCALHOSTNAME=<hostname> export XAUTHORITY=<xauthfile> export $( dbus-launch ) kwin_x11 & plasmashell & But I can't find out, why it doesn't do it automatically. Somenthing with dbus?
Is krunner running? Please attach the journal for the relevant timeframe.
No, krunner isn't running, when this problem occurs. And there are no relevant entries in the journal - really nothing, neither errors nor warnings and not even informational entries. I attach the complete journal from one boot, where this problem occurred.
Created attachment 857160 [details] journal
startplasma-x11 is started, but doesn't print any messages. Is there anything in ~/.local/share/sddm/xorg-session.log? If not, which user processes are running after login?
Reducing severity, because it works with a few manual actions.
(In reply to Fabian Vogt from comment #5) > startplasma-x11 is started, but doesn't print any messages. > > Is there anything in ~/.local/share/sddm/xorg-session.log? > If not, which user processes are running after login? This is from the latest try: dbus-update-activation-environment: error: unable to connect to D-Bus: /usr/bin/dbus-launch terminated abnormally with the following error: Autolaunch requested, but X11 support not compiled in. Cannot continue.
I'm going to start from scratch to get a clean log, because it is not sure, what the original messages were, and what came from my starting script.
Is dbus-1-x11 installed? If yes, what does /etc/alternatives/dbus-launch point to? If you log in a tty, is $DBUS_SESSION_BUS_ADDRESS set? What's the output of "systemctl --user status"?
(In reply to Fabian Vogt from comment #9) > Is dbus-1-x11 installed? If yes, what does /etc/alternatives/dbus-launch > point to? > > If you log in a tty, is $DBUS_SESSION_BUS_ADDRESS set? What's the output of > "systemctl --user status"? First of all - the message above really is the only error entry in this log, whe the error occurs. dbus-1-x11-1.14.0-2.1.x86_64 is installed. ls -l /etc/alternatives/dbus-launch lrwxrwxrwx 1 root root 26 Mar 17 17:51 /etc/alternatives/dbus-launch -> /usr/bin/dbus-launch.nox11 I guess, this might be the problem? It should point to dbus-launch.x11? This is not listed in yast alternatives.
But: alternatives --set dbus-launch /usr/bin/dbus-launch.x11 update-alternatives: error: alternative /usr/bin/dbus-launch.x11 for dbus-launch not registered; not setting Is the syntax incorrect?
And: alternatives --config dbus-launch There is only one alternative in link group dbus-launch (providing /usr/bin/dbus-launch): /usr/bin/dbus-launch.nox11 Nothing to configure.
(In reply to Fabian Vogt from comment #9) > Is dbus-1-x11 installed? If yes, what does /etc/alternatives/dbus-launch > point to? > > If you log in a tty, is $DBUS_SESSION_BUS_ADDRESS set? What's the output of > "systemctl --user status"? DBUS_SESSION_BUS_ADDRESS ist not set in a tty. systemctl --user status ● transformer State: running Jobs: 0 queued Failed: 0 units Since: Thu 2022-03-17 21:49:45 CET; 8min ago CGroup: /user.slice/user-10000.slice/user@10000.service ├─session.slice │ └─pulseaudio.service │ └─18128 /usr/bin/pulseaudio --daemonize=no --log-target=journal └─init.scope ├─17485 /usr/lib/systemd/systemd --user └─17486 (sd-pam)
(In reply to Michael Hirmke from comment #10) > (In reply to Fabian Vogt from comment #9) > > Is dbus-1-x11 installed? If yes, what does /etc/alternatives/dbus-launch > > point to? > > > > If you log in a tty, is $DBUS_SESSION_BUS_ADDRESS set? What's the output of > > "systemctl --user status"? > > First of all - the message above really is the only error entry in this log, > whe the error occurs. > dbus-1-x11-1.14.0-2.1.x86_64 is installed. > > ls -l /etc/alternatives/dbus-launch > lrwxrwxrwx 1 root root 26 Mar 17 17:51 /etc/alternatives/dbus-launch -> > /usr/bin/dbus-launch.nox11 > > I guess, this might be the problem? > It should point to dbus-launch.x11? > > This is not listed in yast alternatives. It looks like the switch away from update-alternatives in dbus-1 wasn't done completely, please try https://build.opensuse.org/package/show/home:Vogtinator:branches:Base:System/dbus-1. (In reply to Michael Hirmke from comment #13) > (In reply to Fabian Vogt from comment #9) > > Is dbus-1-x11 installed? If yes, what does /etc/alternatives/dbus-launch > > point to? > > > > If you log in a tty, is $DBUS_SESSION_BUS_ADDRESS set? What's the output of > > "systemctl --user status"? > > DBUS_SESSION_BUS_ADDRESS ist not set in a tty. > > systemctl --user status > > ● transformer > State: running > Jobs: 0 queued > Failed: 0 units > Since: Thu 2022-03-17 21:49:45 CET; 8min ago > CGroup: /user.slice/user-10000.slice/user@10000.service > ├─session.slice > │ └─pulseaudio.service > │ └─18128 /usr/bin/pulseaudio --daemonize=no > --log-target=journal > └─init.scope > ├─17485 /usr/lib/systemd/systemd --user > └─17486 (sd-pam) Ok, so that's also broken... At least systemd --user is running. Does `systemctl --user start dbus.socket` work?
(In reply to Fabian Vogt from comment #14) > (In reply to Michael Hirmke from comment #10) > > (In reply to Fabian Vogt from comment #9) > > > Is dbus-1-x11 installed? If yes, what does /etc/alternatives/dbus-launch > > > point to? > > > > > > If you log in a tty, is $DBUS_SESSION_BUS_ADDRESS set? What's the output of > > > "systemctl --user status"? > > > > First of all - the message above really is the only error entry in this log, > > whe the error occurs. > > dbus-1-x11-1.14.0-2.1.x86_64 is installed. > > > > ls -l /etc/alternatives/dbus-launch > > lrwxrwxrwx 1 root root 26 Mar 17 17:51 /etc/alternatives/dbus-launch -> > > /usr/bin/dbus-launch.nox11 > > > > I guess, this might be the problem? > > It should point to dbus-launch.x11? > > > > This is not listed in yast alternatives. > > It looks like the switch away from update-alternatives in dbus-1 wasn't done > completely, please try > https://build.opensuse.org/package/show/home:Vogtinator:branches:Base:System/ > dbus-1. > Do I add this as a new repo or do I have to download and install the rpm files?
Got it: https://download.opensuse.org/repositories/home:/Vogtinator:/branches:/Base:/System/openSUSE_Tumbleweed/
(In reply to Michael Hirmke from comment #16) > Got it: > > https://download.opensuse.org/repositories/home:/Vogtinator:/branches:/Base:/ > System/openSUSE_Tumbleweed/ Added the repo, updated dbus-1 and the dependent libraries and rebootet the machine, but to no avail: Same behaviour, same error message in ~/.local/share/sddm/xorg-session.log.
(In reply to Michael Hirmke from comment #17) > (In reply to Michael Hirmke from comment #16) > > Got it: > > > > https://download.opensuse.org/repositories/home:/Vogtinator:/branches:/Base:/ > > System/openSUSE_Tumbleweed/ > > Added the repo, updated dbus-1 and the dependent libraries and rebootet the > machine, but to no avail: Same behaviour, same error message in > ~/.local/share/sddm/xorg-session.log. There was another bug in dbus (https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/263), I added a workaround. Can you update and try again?
(In reply to Fabian Vogt from comment #18) > (In reply to Michael Hirmke from comment #17) > > (In reply to Michael Hirmke from comment #16) > > > Got it: > > > > > > https://download.opensuse.org/repositories/home:/Vogtinator:/branches:/Base:/ > > > System/openSUSE_Tumbleweed/ > > > > Added the repo, updated dbus-1 and the dependent libraries and rebootet the > > machine, but to no avail: Same behaviour, same error message in > > ~/.local/share/sddm/xorg-session.log. > > There was another bug in dbus > (https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/263), I added a > workaround. Can you update and try again? Jepp, back to normal. The latest update seems to have solved the problem. Thx a lot!
Just out of curiosity: Why did this bug hit only me? I didn't see any report about it - neither in the mailing lists nor on the net.
(In reply to Michael Hirmke from comment #20) > Just out of curiosity: Why did this bug hit only me? Normally dbus is already started during login through pam_systemd, but in your case that's somehow broken as well. So the first application using dbus triggers dbus autolaunching, which requires X11 integration. What does "systemctl --user status dbus.socket" say in the TTY? What does "systemctl --user start dbus.socket" do? Note that you'll have to run that after logging out graphically and waiting until the sessions are dead or use loginctl terminate-session. > I didn't see any report about it - neither in the mailing lists nor on the net. There is https://old.reddit.com/r/openSUSE/comments/tgmybr/issue_with_latest_tw_updates/
(In reply to Fabian Vogt from comment #21) > (In reply to Michael Hirmke from comment #20) > > Just out of curiosity: Why did this bug hit only me? > > Normally dbus is already started during login through pam_systemd, but in > your case that's somehow broken as well. So the first application using dbus > triggers dbus autolaunching, which requires X11 integration. > > What does "systemctl --user status dbus.socket" say in the TTY? What does > "systemctl --user start dbus.socket" do? Note that you'll have to run that > after logging out graphically and waiting until the sessions are dead or use > loginctl terminate-session. ● dbus.socket - D-Bus Message Bus Socket Loaded: loaded (/etc/xdg/systemd/user/dbus.socket; enabled; vendor preset: disabled) Active: active (listening) since Fri 2022-03-18 12:04:58 CET; 29s ago Triggers: ● dbus.service Listen: /run/user/10000/dbus/user_bus_socket (Stream) CGroup: /user.slice/user-10000.slice/user@10000.service/app.slice/dbus.socket At least after installing your bugfix, dbus.socket ist started. I waited for all my processes to have stopped, before I logged in again with my account on atty. > > > I didn't see any report about it - neither in the mailing lists nor on the net. > > There is > https://old.reddit.com/r/openSUSE/comments/tgmybr/ > issue_with_latest_tw_updates/ Did Not Connect: Potential Security Issue Firefox detected a potential security threat and did not continue to old.reddit.com because this website requires a secure connection. old.reddit.com has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site.
(In reply to Michael Hirmke from comment #22) > ● dbus.socket - D-Bus Message Bus Socket > Loaded: loaded (/etc/xdg/systemd/user/dbus.socket; enabled; vendor > preset: disabled) Wait, isn't dbus.socket supposed to be a static unit? Why is the socket loaded from /etc/xdg/systemd/user? And why does /etc/xdg/systemd/user/dbus.socket even exist, doesn't dbus.socket lack any [Install] section to begin with and should therefore never end up in any /etc path? Something seems very messed up here... On my systems which are all working the output looks like this: ● dbus.socket - D-Bus User Message Bus Socket Loaded: loaded (/usr/lib/systemd/user/dbus.socket; static) Alternative link to reddit issue: https://www.reddit.com/r/openSUSE/comments/tgmybr/issue_with_latest_tw_updates/
(In reply to Simon Vogl from comment #23) > (In reply to Michael Hirmke from comment #22) > > ● dbus.socket - D-Bus Message Bus Socket > > Loaded: loaded (/etc/xdg/systemd/user/dbus.socket; enabled; vendor > > preset: disabled) > > Wait, isn't dbus.socket supposed to be a static unit? > Why is the socket loaded from /etc/xdg/systemd/user? > And why does /etc/xdg/systemd/user/dbus.socket even exist, doesn't > dbus.socket lack any [Install] section to begin with and should therefore > never end up in any /etc path? Something seems very messed up here... Yep, that's most likely the issue. The output shows that it's missing the ExecStartPost= line, which is responsible for setting $DBUS_SESSION_BUS_ADDRESS. Can you find out where /etc/xdg/systemd/user/dbus.socket is coming from? The btime/mtime might help, I don't think it's owned by any package (rpm -qf).
(In reply to Fabian Vogt from comment #24) > (In reply to Simon Vogl from comment #23) > > (In reply to Michael Hirmke from comment #22) > > > ● dbus.socket - D-Bus Message Bus Socket > > > Loaded: loaded (/etc/xdg/systemd/user/dbus.socket; enabled; vendor > > > preset: disabled) > > > > Wait, isn't dbus.socket supposed to be a static unit? > > Why is the socket loaded from /etc/xdg/systemd/user? > > And why does /etc/xdg/systemd/user/dbus.socket even exist, doesn't > > dbus.socket lack any [Install] section to begin with and should therefore > > never end up in any /etc path? Something seems very messed up here... > > Yep, that's most likely the issue. The output shows that it's missing the > ExecStartPost= line, which is responsible for setting > $DBUS_SESSION_BUS_ADDRESS. > > Can you find out where /etc/xdg/systemd/user/dbus.socket is coming from? The > btime/mtime might help, I don't think it's owned by any package (rpm -qf). rpm -qf /etc/xdg/systemd/user/dbus.socket file /etc/xdg/systemd/user/dbus.socket is not owned by any package stat /etc/xdg/systemd/user/dbus.socket File: /etc/xdg/systemd/user/dbus.socket Size: 158 Blocks: 8 IO Block: 4096 regular file Device: 254,0 Inode: 24252788 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2022-03-18 11:11:13.074425677 +0100 Modify: 2014-01-24 17:32:58.044228000 +0100 Change: 2022-01-20 16:37:47.124090490 +0100 Birth: 2022-01-20 16:37:47.124090490 +0100 contents: [Unit] Description=D-Bus Message Bus Socket Before=sockets.target [Socket] ListenStream=/run/user/%U/dbus/user_bus_socket [Install] WantedBy=default.target So the file is ancient, but the system is even more ancient. It was updated for at least 14 years from one openSUSE version to the next til it arrived at Tumbelweed. But it also worked for ages without any problem up to the before last snanpshot.
Is there anything I should change to reflect the actual contents of the distribution? If so, what exactly?
(In reply to Michael Hirmke from comment #26) > Is there anything I should change to reflect the actual contents of the > distribution? > If so, what exactly? ! Make a btrfs snapshot/backup before you try this ! You could try the following commands: sudo systemctl --global disable dbus.socket And possibly (may not be necessary): sudo systemctl disable dbus.socket If none of the above commands work (the second one may not be necessary), you could also try force-removing the service files manually: sudo rm /etc/xdg/systemd/user/dbus.socket sudo rm /etc/systemd/user/dbus.socket And possibly (may not be necessary): sudo rm /etc/xdg/systemd/system/dbus.socket sudo rm /etc/systemd/system/dbus.socket After that, reboot, and check if the output of systemctl --user status dbus.socket looks like this: ● dbus.socket - D-Bus User Message Bus Socket Loaded: loaded (/usr/lib/systemd/user/dbus.socket; static)
(In reply to Simon Vogl from comment #27) > (In reply to Michael Hirmke from comment #26) > > Is there anything I should change to reflect the actual contents of the > > distribution? > > If so, what exactly? > > ! Make a btrfs snapshot/backup before you try this ! Sadly this isn't a system with btrfs, but with ext4. Backing up is't possible at the moment because I am not at home. So I'd better wait til I will be back home again. > > You could try the following commands: > sudo systemctl --global disable dbus.socket > > And possibly (may not be necessary): > > sudo systemctl disable dbus.socket > > If none of the above commands work (the second one may not be necessary), > you could also try force-removing the service files manually: > > sudo rm /etc/xdg/systemd/user/dbus.socket > sudo rm /etc/systemd/user/dbus.socket > > And possibly (may not be necessary): > > sudo rm /etc/xdg/systemd/system/dbus.socket > sudo rm /etc/systemd/system/dbus.socket > > After that, reboot, and check if the output of systemctl --user status > dbus.socket looks like this: > > ● dbus.socket - D-Bus User Message Bus Socket > Loaded: loaded (/usr/lib/systemd/user/dbus.socket; static) Thx or your answer!
You can just remove /etc/xdg/systemd/user/dbus.socket and reboot, it should be reasonably safe. You can rename it temporarily as backup if you want. (In reply to Simon Vogl from comment #27) > (In reply to Michael Hirmke from comment #26) > > Is there anything I should change to reflect the actual contents of the > > distribution? > > If so, what exactly? > > ! Make a btrfs snapshot/backup before you try this ! > > You could try the following commands: > sudo systemctl --global disable dbus.socket > > And possibly (may not be necessary): > > sudo systemctl disable dbus.socket Do NOT run any of those two commands, they WILL break your system! They won't get rid of the broken dbus.socket from /etc, instead they'll disable dbus completely, the second one even the system DBus instance.
(In reply to Fabian Vogt from comment #29) > You can just remove /etc/xdg/systemd/user/dbus.socket and reboot, it should > be reasonably safe. > > You can rename it temporarily as backup if you want. > What about dbus.service in the same directory with the same age? complete contents: [/etc/xdg/systemd/user]_$ls -laR .: total 24 drwxr-xr-x 4 root root 4096 Mar 9 20:12 . drwxr-xr-x 14 root root 4096 Mar 9 20:12 .. -rw-r--r-- 1 root root 300 Jan 24 2014 dbus.service -rw-r--r-- 1 root root 158 Jan 24 2014 dbus.socket drwxr-xr-x 2 root root 4096 Jun 23 2018 default.target.wants drwxr-xr-x 2 root root 4096 Dec 12 22:13 sockets.target.wants ./default.target.wants: total 8 drwxr-xr-x 2 root root 4096 Jun 23 2018 . drwxr-xr-x 4 root root 4096 Mar 9 20:12 .. lrwxrwxrwx 1 root root 29 Jan 24 2014 dbus.socket -> /etc/systemd/user/dbus.socket ./sockets.target.wants: total 8 drwxr-xr-x 2 root root 4096 Dec 12 22:13 . drwxr-xr-x 4 root root 4096 Mar 9 20:12 .. lrwxrwxrwx 1 root root 39 Dec 12 22:13 pulseaudio.socket -> /usr/lib/systemd/user/pulseaudio.socket /etc/xdg/systemd/user itself is a link pointing to /etc/systemd/user.
(In reply to Fabian Vogt from comment #29) > You can just remove /etc/xdg/systemd/user/dbus.socket and reboot, it should > be reasonably safe. > > You can rename it temporarily as backup if you want. > > (In reply to Simon Vogl from comment #27) > > (In reply to Michael Hirmke from comment #26) > > > Is there anything I should change to reflect the actual contents of the > > > distribution? > > > If so, what exactly? > > > > ! Make a btrfs snapshot/backup before you try this ! > > > > You could try the following commands: > > <dangerous command> > > > > And possibly (may not be necessary): > > > > <dangerous command> > > Do NOT run any of those two commands, they WILL break your system! > They won't get rid of the broken dbus.socket from /etc, instead they'll > disable dbus completely, the second one even the system DBus instance. Oh my god, I didn't know that, I'm deeply sorry. Any way to delete my original post? Interestingly, if I run these commands on my systems simply nothing happens for some reason. Maybe it's only destructive if you do it with dbus.service instead of dbus.socket?
I did some more research on the commands: > They won't get rid of the broken dbus.socket from /etc Absolutely true, I should have known :( > instead they'll disable dbus completely, the second one even the system DBus instance. To my understanding fortunately both dbus.service and dbus.socket are static units in modern versions of dbus, meaning they cannot be disabled via the "systemctl disable" command any more. That's probably the reason why the commands did nothing on my system and that made me somehow believe they are safe to use. However: In older versions of dbus, dbus.service and dbus.socket are non-static, and the command would be VERY destructive in that case. Old leap version users beware! If you run the commands with .service instead of .socket, they can also switch you back from dbus-broker to dbus-daemon in case you use dbus-broker. Still, OP should definitely not use those commands, at best they don't do anything and at worst they can prevent some older systems from booting. Again, I'm very sorry for posting random stuff I didn't properly research, I hope you can forgive me.
(In reply to Michael Hirmke from comment #30) > (In reply to Fabian Vogt from comment #29) > > You can just remove /etc/xdg/systemd/user/dbus.socket and reboot, it should > > be reasonably safe. > > > > You can rename it temporarily as backup if you want. > > What about dbus.service in the same directory with the same age? Yeah, you can delete that as well. (In reply to Simon Vogl from comment #31) > (In reply to Fabian Vogt from comment #29) > > You can just remove /etc/xdg/systemd/user/dbus.socket and reboot, it should > > be reasonably safe. > > > > You can rename it temporarily as backup if you want. > > > > (In reply to Simon Vogl from comment #27) > > > (In reply to Michael Hirmke from comment #26) > > > > Is there anything I should change to reflect the actual contents of the > > > > distribution? > > > > If so, what exactly? > > > > > > ! Make a btrfs snapshot/backup before you try this ! > > > > > > You could try the following commands: > > > <dangerous command> > > > > > > And possibly (may not be necessary): > > > > > > <dangerous command> > > > > Do NOT run any of those two commands, they WILL break your system! > > They won't get rid of the broken dbus.socket from /etc, instead they'll > > disable dbus completely, the second one even the system DBus instance. > > Oh my god, I didn't know that, I'm deeply sorry. Any way to delete my > original post? Not possible and hopefully not necessary. > Interestingly, if I run these commands on my systems simply nothing happens > for some reason. Maybe it's only destructive if you do it with dbus.service > instead of dbus.socket? No idea. .socket units (and dbus units) are special anyway (literally, they're documented in systemd.special(7)). I'm not sure what "systemctl disable" actually does to those and I didn't want to try. In the best case it does absolutely nothing, as the other case is that it actually disables something important... (In reply to Simon Vogl from comment #32) > I did some more research on the commands: > > They won't get rid of the broken dbus.socket from /etc > Absolutely true, I should have known :( > > instead they'll disable dbus completely, the second one even the system DBus instance. > To my understanding fortunately both dbus.service and dbus.socket are static > units in modern versions of dbus, meaning they cannot be disabled via the > "systemctl disable" command any more. That's probably the reason why the > commands did nothing on my system and that made me somehow believe they are > safe to use. > > However: In older versions of dbus, dbus.service and dbus.socket are > non-static, and the command would be VERY destructive in that case. Old leap > version users beware! If you run the commands with .service instead of > .socket, they can also switch you back from dbus-broker to dbus-daemon in > case you use dbus-broker. In OP's case, the user dbus.socket is not static, so disabling that might actually disable the unit, rendering user sessions incomplete. If the system unit has a similar issue, then systemctl disable on that might have a negative impact as well. > Still, OP should definitely not use those commands, at best they don't do > anything and at worst they can prevent some older systems from booting. Yep. > Again, I'm very sorry for posting random stuff I didn't properly research, I > hope you can forgive me. That's absolutely not an issue! That's sometimes the best way to learn stuff. It's not like everyone writes 100% correct information all the time... TIL that disabling static units is (probably) a noop.
I'm having the same issue that Michael is having so: -I added the repository and updated dbus-1 -I made sure it and the supporting files were updated -I rebooted and made sure dbus-1 was still the updated version -I then updated TW and rebooted. Same issue: I get a black screen with a mouse pointer instead of the normal login screen. I went to a tty and checked and dbus-1 was still the updated version. Did I miss a step along the way with regards to the updated dbus? Note: When I update TW and it completes, Plasma become slow, you can't open any new applications, and I cannot reboot or shutdown via the GUI. I have to issue a sudo reboot. It has been this way since the updates on Thursday. I then have to rollback. I apologize, I'm working on a large project this weekend for work so I did not have time to try anything else. Thanks!
(In reply to Mark Hart from comment #34) > I'm having the same issue that Michael is having so: > > -I added the repository and updated dbus-1 > -I made sure it and the supporting files were updated > -I rebooted and made sure dbus-1 was still the updated version > -I then updated TW and rebooted. > > Same issue: I get a black screen with a mouse pointer instead of the normal > login screen. > > I went to a tty and checked and dbus-1 was still the updated version. > > > Did I miss a step along the way with regards to the updated dbus? > > Note: When I update TW and it completes, Plasma become slow, you can't open > any new applications, and I cannot reboot or shutdown via the GUI. I have to > issue a sudo reboot. It has been this way since the updates on Thursday. > > I then have to rollback. > > I apologize, I'm working on a large project this weekend for work so I did > not have time to try anything else. > > Thanks! Could you post the output of the command systemctl --user status dbus.socket and sudo systemctl status dbus.socket aswell? You might have those depreciated files on your system aswell... I managed to reproduced the issue by manually adding the old dbus.socket file to /etc/systemd/user/dbus.socket on my working systems.
(In reply to Simon Vogl from comment #35) > (In reply to Mark Hart from comment #34) > > I'm having the same issue that Michael is having so: > > > > -I added the repository and updated dbus-1 > > -I made sure it and the supporting files were updated > > -I rebooted and made sure dbus-1 was still the updated version > > -I then updated TW and rebooted. > > > > Same issue: I get a black screen with a mouse pointer instead of the normal > > login screen. > > > > I went to a tty and checked and dbus-1 was still the updated version. > > > > > > Did I miss a step along the way with regards to the updated dbus? > > > > Note: When I update TW and it completes, Plasma become slow, you can't open > > any new applications, and I cannot reboot or shutdown via the GUI. I have to > > issue a sudo reboot. It has been this way since the updates on Thursday. > > > > I then have to rollback. > > > > I apologize, I'm working on a large project this weekend for work so I did > > not have time to try anything else. > > > > Thanks! > > Could you post the output of the command > > systemctl --user status dbus.socket > > and > > sudo systemctl status dbus.socket > > aswell? You might have those depreciated files on your system aswell... > I managed to reproduced the issue by manually adding the old dbus.socket > file to /etc/systemd/user/dbus.socket on my working systems. Thank you for the help! :-) Let me know if you need anything else! --------- Before TW Updates ----------- mark@localhost:~> sudo systemctl --user status dbus.socket [sudo] password for root: Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user) mark@localhost:~> sudo systemctl status dbus.socket ● dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (/usr/lib/systemd/system/dbus.socket; static) Active: active (running) since Sat 2022-03-19 17:40:37 EDT; 3h 19min ago Triggers: ● dbus.service Listen: /run/dbus/system_bus_socket (Stream) CGroup: /system.slice/dbus.socket Mar 19 17:40:37 localhost systemd[1]: Listening on D-Bus System Message Bus Socket. mark@localhost:~> --------- After TW Updates ---------- ● dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (/usr/lib/systemd/system/dbus.socket; static) Active: active (running) since Sat 2022-03-19 21:19:46 EDT; 33min ago Triggers: ● dbus.service Listen: /run/dbus/system_bus_socket (Stream) CGroup: /system.slice/dbus.socket Mar 19 21:19:46 localhost systemd[1]: Listening on D-Bus System Message Bus Socket. ● dbus.socket - D-Bus User Message Bus Socket Loaded: loaded (/usr/lib/systemd/user/dbus.socket; static) Active: active (listening) since Sat 2022-03-19 21:20:20 EDT; 31min ago Triggers: ● dbus.service Listen: /run/user/1000/bus (Stream) Process: 2002 ExecStartPost=/usr/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) Memory: 0B CPU: 3ms CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/dbus.socket Mar 19 21:20:20 localhost.localdomain systemd[1995]: Starting D-Bus User Message Bus Socket... Mar 19 21:20:20 localhost.localdomain systemd[1995]: Listening on D-Bus User Message Bus Socket.
(In reply to Fabian Vogt from comment #33) > (In reply to Michael Hirmke from comment #30) > > (In reply to Fabian Vogt from comment #29) > > > You can just remove /etc/xdg/systemd/user/dbus.socket and reboot, it should > > > be reasonably safe. > > > > > > You can rename it temporarily as backup if you want. > > > > What about dbus.service in the same directory with the same age? > > Yeah, you can delete that as well. > Thx! I moved dbus.socket and dbus.service to a backup directory and rebooted. Afterwards I get: From within a tty: ● dbus.socket - D-Bus User Message Bus Socket Loaded: loaded (/usr/lib/systemd/user/dbus.socket; enabled; vendor preset: disabled) Active: active (listening) since Sun 2022-03-20 07:40:53 CET; 33s ago Triggers: ● dbus.service Listen: /run/user/10000/bus (Stream) Process: 1843 ExecStartPost=/usr/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/10000/bus (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) Memory: 0B CPU: 24ms CGroup: /user.slice/user-10000.slice/user@10000.service/app.slice/dbus.socket ○ dbus.service - D-Bus User Message Bus Loaded: loaded (/usr/lib/systemd/user/dbus.service; static) Active: inactive (dead) TriggeredBy: ● dbus.socket Docs: man:dbus-daemon(1) From within a KDE session: ● dbus.socket - D-Bus User Message Bus Socket Loaded: loaded (/usr/lib/systemd/user/dbus.socket; enabled; vendor preset: disabled) Active: active (running) since Sun 2022-03-20 07:44:29 CET; 3min 4s ago Triggers: ● dbus.service Listen: /run/user/10000/bus (Stream) Tasks: 0 (limit: 4915) Memory: 4.0K CPU: 24ms CGroup: /user.slice/user-10000.slice/user@10000.service/app.slice/dbus.socket ● dbus.service - D-Bus User Message Bus Loaded: loaded (/usr/lib/systemd/user/dbus.service; static) Active: active (running) since Sun 2022-03-20 07:44:29 CET; 3min 7s ago TriggeredBy: ● dbus.socket Docs: man:dbus-daemon(1) Main PID: 5309 (dbus-daemon) Tasks: 15 (limit: 4915) Memory: 23.7M CPU: 1.300s CGroup: /user.slice/user-10000.slice/user@10000.service/session.slice/dbus.service ├─5309 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only ├─5626 /usr/lib64/ibus/ibus-portal ├─5885 /usr/libexec/goa-daemon ├─5935 /usr/libexec/goa-identity-service └─6011 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets Logging in to a KDE session still works with kwin and plasmashell getting started. One pitfall, though: If I log out and immediatly log back in, I get the same problem again - black screen with movable mouse cursor. If I wait for a few seconds, til all my processes have been stopped, I can log in without having this problem.
(In reply to Michael Hirmke from comment #37) > ● dbus.socket - D-Bus User Message Bus Socket > Loaded: loaded (/usr/lib/systemd/user/dbus.socket; enabled; vendor > preset: disabled) > ... > ● dbus.socket - D-Bus User Message Bus Socket > Loaded: loaded (/usr/lib/systemd/user/dbus.socket; enabled; vendor > preset: disabled) Oh no, it looks like for some reason the file /usr/lib/systemd/user/dbus.socket does not reflect the file found in the dbus-1 RPM package on your system and is still from an ancient version of dbus-1..... But why did RPM not update it? (In reply to Mark Hart from comment #36) > ● dbus.socket - D-Bus System Message Bus Socket > Loaded: loaded (/usr/lib/systemd/system/dbus.socket; static) > ● dbus.socket - D-Bus User Message Bus Socket > Loaded: loaded (/usr/lib/systemd/user/dbus.socket; static) This does look like it's supposed to, so there seems to be something else than broken service files triggering this aswell...
(In reply to Simon Vogl from comment #38) > (In reply to Michael Hirmke from comment #37) > > ● dbus.socket - D-Bus User Message Bus Socket > > Loaded: loaded (/usr/lib/systemd/user/dbus.socket; enabled; vendor > > preset: disabled) > > ... > > ● dbus.socket - D-Bus User Message Bus Socket > > Loaded: loaded (/usr/lib/systemd/user/dbus.socket; enabled; vendor > > preset: disabled) > > Oh no, it looks like for some reason the file > /usr/lib/systemd/user/dbus.socket does not reflect the file found in the > dbus-1 RPM package on your system and is still from an ancient version of > dbus-1..... > But why did RPM not update it? > Where do you see a problem here? ls -la /usr/lib/systemd/user/dbus.* -rw-r--r-- 1 root root 410 Mar 18 10:53 /usr/lib/systemd/user/dbus.service -rw-r--r-- 1 root root 178 Mar 18 10:53 /usr/lib/systemd/user/dbus.socket rpm -qf /usr/lib/systemd/user/dbus.service dbus-1-1.14.0-357.1.x86_64 rpm -qf /usr/lib/systemd/user/dbus.socket dbus-1-1.14.0-357.1.x86_64 rpm -qi dbus-1-1.14.0-357.1.x86_64 Name : dbus-1 Version : 1.14.0 Release : 357.1 Architecture: x86_64 Install Date: Fri Mar 18 11:10:32 2022 Group : Unspecified Size : 660429 License : AFL-2.1 OR GPL-2.0-or-later Signature : RSA/SHA256, Fri Mar 18 10:54:12 2022, Key ID 0966a3396cd6949b Source RPM : dbus-1-1.14.0-357.1.src.rpm Build Date : Fri Mar 18 10:53:13 2022 Build Host : lamb61 Vendor : obs://build.opensuse.org/home:Vogtinator URL : https://dbus.freedesktop.org/ Summary : D-Bus Message Bus System Looks perfectly ok!?!
(In reply to Michael Hirmke from comment #39) > (In reply to Simon Vogl from comment #38) > > (In reply to Michael Hirmke from comment #37) > > > ● dbus.socket - D-Bus User Message Bus Socket > > > Loaded: loaded (/usr/lib/systemd/user/dbus.socket; enabled; vendor > > > preset: disabled) > > > ... > > > ● dbus.socket - D-Bus User Message Bus Socket > > > Loaded: loaded (/usr/lib/systemd/user/dbus.socket; enabled; vendor > > > preset: disabled) > > > > Oh no, it looks like for some reason the file > > /usr/lib/systemd/user/dbus.socket does not reflect the file found in the > > dbus-1 RPM package on your system and is still from an ancient version of > > dbus-1..... > > But why did RPM not update it? > > > > Where do you see a problem here? > > ls -la /usr/lib/systemd/user/dbus.* > -rw-r--r-- 1 root root 410 Mar 18 10:53 /usr/lib/systemd/user/dbus.service > -rw-r--r-- 1 root root 178 Mar 18 10:53 /usr/lib/systemd/user/dbus.socket > > rpm -qf /usr/lib/systemd/user/dbus.service > dbus-1-1.14.0-357.1.x86_64 > rpm -qf /usr/lib/systemd/user/dbus.socket > dbus-1-1.14.0-357.1.x86_64 > > rpm -qi dbus-1-1.14.0-357.1.x86_64 > Name : dbus-1 > Version : 1.14.0 > Release : 357.1 > Architecture: x86_64 > Install Date: Fri Mar 18 11:10:32 2022 > Group : Unspecified > Size : 660429 > License : AFL-2.1 OR GPL-2.0-or-later > Signature : RSA/SHA256, Fri Mar 18 10:54:12 2022, Key ID 0966a3396cd6949b > Source RPM : dbus-1-1.14.0-357.1.src.rpm > Build Date : Fri Mar 18 10:53:13 2022 > Build Host : lamb61 > Vendor : obs://build.opensuse.org/home:Vogtinator > URL : https://dbus.freedesktop.org/ > Summary : D-Bus Message Bus System > > Looks perfectly ok!?! It's not that dramatic, I just find awkward that dbus.socket shows "enabled; vendor preset: disabled" as the status for dbus.socket. However, normally it should be a static unit and it should show "static" in this place. Could you post the content of the file /usr/lib/systemd/user/dbus.socket?
Michael and Simon, Do you think my issue is related to the same issue Michael is having? I also have three more users with the same issue. We are all on TW with the same HP laptops. I have installed a lot more software because of projects that I'm working on so when I had issues I thought it might be something I had done. However, the other three are running TW, Eclipse, LibreOffice, WINE, and LibreWolf. Straight forward systems if you will. I tried Michael's suggestion: export DISPLAY=:0 export XAUTHLOCALHOSTNAME=localhost export XAUTHORITY=.Xauthority export $( dbus-launch ) kwin_x11 & plasmashell & However, I get a protocol error after export $( dbus-launch ) so I can't launch plasma. Thank!
(In reply to Mark Hart from comment #41) > Michael and Simon, > > Do you think my issue is related to the same issue Michael is having? I also > have three more users with the same issue. We are all on TW with the same HP > laptops. > > I have installed a lot more software because of projects that I'm working on > so when I had issues I thought it might be something I had done. However, > the other three are running TW, Eclipse, LibreOffice, WINE, and LibreWolf. > Straight forward systems if you will. > > I tried Michael's suggestion: > > export DISPLAY=:0 > export XAUTHLOCALHOSTNAME=localhost I used the real name of the machine. It should match the name contained in the xauth file below. > export XAUTHORITY=.Xauthority This is not ~/.Xauthority, but /run/user/<id>/xauth_<whatever> > export $( dbus-launch ) > kwin_x11 & > plasmashell & > > However, I get a protocol error after export $( dbus-launch ) so I can't > launch plasma. > > > Thank! Bye. Michael.
(In reply to Simon Vogl from comment #40) [...] > > It's not that dramatic, I just find awkward that dbus.socket shows "enabled; > vendor preset: disabled" as the status for dbus.socket. However, normally it > should be a static unit and it should show "static" in this place. > > Could you post the content of the file /usr/lib/systemd/user/dbus.socket? [Unit] Description=D-Bus User Message Bus Socket [Socket] ListenStream=%t/bus ExecStartPost=-/usr/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus ~ ~
(In reply to Michael Hirmke from comment #43) > (In reply to Simon Vogl from comment #40) > [...] > > > > It's not that dramatic, I just find awkward that dbus.socket shows "enabled; > > vendor preset: disabled" as the status for dbus.socket. However, normally it > > should be a static unit and it should show "static" in this place. > > > > Could you post the content of the file /usr/lib/systemd/user/dbus.socket? > > [Unit] > Description=D-Bus User Message Bus Socket > > [Socket] > ListenStream=%t/bus > ExecStartPost=-/usr/bin/systemctl --user set-environment > DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus > ~ > > ~ Oh, it DOES reflect the correct file from the dbus-1 .rpm file! Forget what I said before... Now the question is why the systemctl command shows the unit as being enabled when really it shouldn't...
(In reply to Simon Vogl from comment #44) > (In reply to Michael Hirmke from comment #43) > > (In reply to Simon Vogl from comment #40) > > [...] > > > > > > It's not that dramatic, I just find awkward that dbus.socket shows "enabled; > > > vendor preset: disabled" as the status for dbus.socket. However, normally it > > > should be a static unit and it should show "static" in this place. > > > > > > Could you post the content of the file /usr/lib/systemd/user/dbus.socket? > > > > [Unit] > > Description=D-Bus User Message Bus Socket > > > > [Socket] > > ListenStream=%t/bus > > ExecStartPost=-/usr/bin/systemctl --user set-environment > > DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus > > ~ > > > > ~ > > Oh, it DOES reflect the correct file from the dbus-1 .rpm file! Forget what > I said before... > Now the question is why the systemctl command shows the unit as being > enabled when really it shouldn't... Perhas because of /usr/lib/systemd/user/sockets.target.wants/dbus.socket ?
Latest TW update fixed all my issues. Thanks for all the help! I know you are busy so I sincerely appreciate your time and knowledge!
Works as expected now.