dbus-broker.service: Exiting due to fatal error: -2

arc891 · 2024-05-03 13:49:59

arc891 wrote:

Edit 3: Even though pulseaudio gives those errors after a boot and fails, pulseaudio does still manage to start up after a manual 'systemctl --user start pulseaudio' without issues. Not sure if helpful/related, but figured I'd add it.

Also not true, this thing is confusing the hell out of me. Now it's not starting up again either. Do you have any idea where I can look next or what else I can try seth?

seth · 2024-05-03 14:31:51

The last journal only has a login of your "arc" UID, not the test user.
Remove the pipewire/pulseaudio related userservice adjustments (mask and want) and replace pulseaudio w/ pipewire-pulse for a proper pipewire installation.
If
1. this resolves the dbus issues but
2. leaves you with sound problems, it's probably easier to focus on the latter two.

arc891 · 2024-05-03 15:34:54

seth wrote:

The last journal only has a login of your "arc" UID, not the test user.

Ah, mb on the journal log.

seth wrote:

Remove the pipewire/pulseaudio related userservice adjustments (mask and want) and replace pulseaudio w/ pipewire-pulse for a proper pipewire installation.
If
1. this resolves the dbus issues but
2. leaves you with sound problems, it's probably easier to focus on the latter two.

That makes a lot of sense.
I made sure there were no masks left before I reinstalled pipewire-pulse like you said. After installing it however, it seemed like the same issues still occur, if not more But perhaps those can give better insights.
Here's my current 'sudo journalctl -b' of my arc user: http://0x0.st/XX4v.txt.

I looked into "pipewire[2485]: pw.conf: 0x5f15fa195b90: could not load mandatory module "libpipewire-module-protocol-native": No such file or directory" by trying to install 'libpipewire', but this was already installed and reinstalling made no difference.

From all these logs, to me it's starting to look more like the issue is not being caused by PA/PW, but more that the dbus-issue is causing PA & PW to fail. The PA & PW logs only start a while after the D-Bus errors occur. However, that would leave us with no lead. I personally cannot find anything weird or incriminating looking info before D-Bus starts acting up. Could this be a D-Bus bug? Perhaps that's the wrong question to ask, but I'm struggling to find where to look next on this.

seth · 2024-05-03 16:13:16

The key issue remains

May 03 17:16:51 arch systemctl[1364]: Failed to connect to bus: No such file or directory
May 03 17:16:51 arch systemctl[1366]: Failed to connect to bus: No such file or directory

everything else is a symptom of that.
The question is "why" and the theory was that your user service stuff caused this (because the test user isn't affected) which doesn't seem to be the case.

You could start to poison the test user w/ the config files of the arc user (~/.* - everything that's prone to be sourced by a shell or systemd, so stuff like ~/.profile or ~/.config/systemd) until the error appears there as well - make sure the test user is using the same $SHELL

An alternative approach would be to

grep -riE '(xdg|dbus)' ~arc

to maybe hit some compromising export.

arc891 · 2024-05-03 19:34:31

seth wrote:

The key issue remains
May 03 17:16:51 arch systemctl[1364]: Failed to connect to bus: No such file or directory
May 03 17:16:51 arch systemctl[1366]: Failed to connect to bus: No such file or directory
everything else is a symptom of that.
The question is "why" and the theory was that your user service stuff caused this (because the test user isn't affected) which doesn't seem to be the case.
You could start to poison the test user w/ the config files of the arc user (~/.* - everything that's prone to be sourced by a shell or systemd, so stuff like ~/.profile or ~/.config/systemd) until the error appears there as well - make sure the test user is using the same $SHELL
An alternative approach would be to
grep -riE '(xdg|dbus)' ~arc
to maybe hit some compromising export.

Alright, that sounds like a plan. I'll be slowly working my way through this, I'll let you know if I find anything. Will probably be somewhere tomorrow I'll be able to update something.

Also, I have already quickly ran the

grep -riE '(xdg|dbus)' ~arc

, that came up with an insanely large output, many binary files found, but if you want I can post that in the meantime. (Edit: nvmd it's 645MB large lmao, might be tough XD)

Last edited by arc891 (2024-05-03 19:43:36)

seth · 2024-05-03 19:36:42

You've binary file in your $HOME? (~arc)
Most of them are probably xdg, but feel free to upload the result to 0x0.st or so - maybe soething sticks out.

arc891 · 2024-05-04 21:26:02

seth wrote:

You've binary file in your $HOME? (~arc)
Most of them are probably xdg, but feel free to upload the result to 0x0.st or so - maybe soething sticks out.

Yeah, my $HOME contains some like chrome and spotify binaries etc in my .conf . But yeah, there also quite some personal info in there, which will take a bit to filter out, I'll get back to you on that (had a busy day).

Apart from that tho, I have copied most of my $HOME and .config files over to the tempuser, but still no issues as of yet, so I'll keep looking into that and let you know when I manage to reproduce anything.

Arch Linux

#26 2024-05-03 13:49:59

Re: dbus-broker.service: Exiting due to fatal error: -2

#27 2024-05-03 14:31:51

Re: dbus-broker.service: Exiting due to fatal error: -2

#28 2024-05-03 15:34:54

Re: dbus-broker.service: Exiting due to fatal error: -2

#29 2024-05-03 16:13:16

Re: dbus-broker.service: Exiting due to fatal error: -2

#30 2024-05-03 19:34:31

Re: dbus-broker.service: Exiting due to fatal error: -2

#31 2024-05-03 19:36:42

Re: dbus-broker.service: Exiting due to fatal error: -2

#32 2024-05-04 21:26:02

Re: dbus-broker.service: Exiting due to fatal error: -2

Board footer