Bug 1197258 - no more plasma after tumbleweed update
no more plasma after tumbleweed update
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 openSUSE Tumbleweed
: P5 - None : Major (vote)
: ---
Assigned To: Fabian Vogt
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-03-17 17:28 UTC by Michael Hirmke
Modified: 2022-03-23 09:36 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
journal (301.62 KB, text/x-log)
2022-03-17 19:54 UTC, Michael Hirmke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Hirmke 2022-03-17 17:28:15 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.
Comment 1 Michael Hirmke 2022-03-17 18:46:09 UTC
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?
Comment 2 Fabian Vogt 2022-03-17 19:44:34 UTC
Is krunner running?

Please attach the journal for the relevant timeframe.
Comment 3 Michael Hirmke 2022-03-17 19:53:55 UTC
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.
Comment 4 Michael Hirmke 2022-03-17 19:54:24 UTC
Created attachment 857160 [details]
journal
Comment 5 Fabian Vogt 2022-03-17 20:12:18 UTC
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?
Comment 6 Michael Hirmke 2022-03-17 20:16:08 UTC
Reducing severity, because it works with a few manual actions.
Comment 7 Michael Hirmke 2022-03-17 20:16:56 UTC
(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.
Comment 8 Michael Hirmke 2022-03-17 20:19:04 UTC
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.
Comment 9 Fabian Vogt 2022-03-17 20:25:32 UTC
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"?
Comment 10 Michael Hirmke 2022-03-17 20:31:03 UTC
(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.
Comment 11 Michael Hirmke 2022-03-17 20:34:00 UTC
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?
Comment 12 Michael Hirmke 2022-03-17 20:34:55 UTC
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.
Comment 13 Michael Hirmke 2022-03-17 20:58:48 UTC
(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)
Comment 14 Fabian Vogt 2022-03-17 21:05:23 UTC
(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?
Comment 15 Michael Hirmke 2022-03-18 06:52:58 UTC
(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?
Comment 17 Michael Hirmke 2022-03-18 07:05:12 UTC
(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.
Comment 18 Fabian Vogt 2022-03-18 09:58:39 UTC
(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?
Comment 19 Michael Hirmke 2022-03-18 10:14:40 UTC
(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!
Comment 20 Michael Hirmke 2022-03-18 10:21:14 UTC
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.
Comment 21 Fabian Vogt 2022-03-18 10:31:38 UTC
(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/
Comment 22 Michael Hirmke 2022-03-18 12:15:25 UTC
(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.
Comment 23 Simon Vogl 2022-03-18 16:45:11 UTC
(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/
Comment 24 Fabian Vogt 2022-03-18 17:05:12 UTC
(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).
Comment 25 Michael Hirmke 2022-03-18 17:18:03 UTC
(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.
Comment 26 Michael Hirmke 2022-03-19 06:50:36 UTC
Is there anything I should change to reflect the actual contents of the distribution?
If so, what exactly?
Comment 27 Simon Vogl 2022-03-19 10:37:33 UTC
(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)
Comment 28 Michael Hirmke 2022-03-19 11:13:08 UTC
(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!
Comment 29 Fabian Vogt 2022-03-19 16:35:07 UTC
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.
Comment 30 Michael Hirmke 2022-03-19 17:30:46 UTC
(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.
Comment 31 Simon Vogl 2022-03-19 18:11:58 UTC
(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?
Comment 32 Simon Vogl 2022-03-19 19:11:25 UTC
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.
Comment 33 Fabian Vogt 2022-03-19 20:02:59 UTC
(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.
Comment 34 Mark Hart 2022-03-19 22:35:45 UTC
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!
Comment 35 Simon Vogl 2022-03-20 00:24:27 UTC
(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.
Comment 36 Mark Hart 2022-03-20 02:06:06 UTC
(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.
Comment 37 Michael Hirmke 2022-03-20 06:51:45 UTC
(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.
Comment 38 Simon Vogl 2022-03-20 09:52:41 UTC
(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...
Comment 39 Michael Hirmke 2022-03-20 10:05:44 UTC
(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!?!
Comment 40 Simon Vogl 2022-03-20 13:06:11 UTC
(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?
Comment 41 Mark Hart 2022-03-20 14:40:51 UTC
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!
Comment 42 Michael Hirmke 2022-03-20 15:18:25 UTC
(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.
Comment 43 Michael Hirmke 2022-03-20 15:20:33 UTC
(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
~                                                                                                                       
~
Comment 44 Simon Vogl 2022-03-20 15:26:51 UTC
(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...
Comment 45 Michael Hirmke 2022-03-20 16:01:09 UTC
(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
?
Comment 46 Mark Hart 2022-03-22 16:13:22 UTC
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!
Comment 47 Michael Hirmke 2022-03-23 09:36:44 UTC
Works as expected now.