dbus-broker-units has made Light Display Manager (lightdm) unable to start

[MR-Diamond]

OS: Manjaro Linux, rolling release.

Today I received a system update, which, in the first place, has asked me to choose to install dbus-broker-units (default and recommended choice) or dbus-daemon-units. As recommended I choosed to install dbus-broker-units (35-2). After reboot, my system was unable to complete the boot: "Failed to start Light Display Manager":

Unfortunately I haven't been able to check the journal log, since I was also unable to open a TTY session: in the end I restored a timeshift backup, performed again the system update, and this time I choosed to install dbus-daemon-units: this time, lightdm, has properly started without errors.

On the Manjaro's forum, a person told me that "Some greeters used by lightdm might not work with the new broker"; this is the content of /etc/lightdm/lightdm.conf:

[LightDM]
run-directory=/run/lightdm
[Seat:*]
greeter-session=lightdm-webkit2-greeter
user-session=xfce
session-wrapper=/etc/lightdm/Xsession
[XDMCPServer]
[VNCServer]

As you can see, I use lightdm-webkit2-greeter. Could be the case of the failure of Light Display Manager?

[dvdhrm]

dbus-broker is unable to start on your machine. This looks unrelated to lightdm, which just happens to also fail to start due to a missing system bus connection.

The journal will likely contain an explanation why the startup failed. Without it, it is quite hard to pinpoint.

[MR-Diamond]

fail to start due to a missing system bus connection.

There is a way to enable this bus connection? I have to start some service/unit?

[dvdhrm]

The only reasonable way to debug this is to get access to the journal of a failed boot. Note that journalctl can show messages of previous boots by using -b<num>, where <num> can be a negative number. E.g., journalctl -b-3 shows the messages of 3 boots ago.

[0xSileo]

I have a similar problem on Manjaro Gnome. Here are some journalctl logs if useful.

[MR-Diamond]

I have a similar problem on Manjaro Gnome. Here are some journalctl logs if useful.

Did you take the log from the failed boot? Eg journalctl -b -1 --no-pager -l (- b -1 for the immediate previous boot) ?

Personally, due to the fact that with dbus-broker I cannot also switch to a TTY, I will take the system log from chroot. But for various reasons I cannot do it soon.

[0xSileo]

I just got it working now. I managed to get a TTY by setting the runlevel to 3 in the grub options (here and here) and installed the dbus-daemon-units package, and made sure dbus-broker-units was removed. I fiddled with the n in journalctl -b -n to get today's logs.

[MR-Diamond]

@sileooo The developers of dbus-broker needs a journalctl -b -1 --no-pager -l from dbus-broker-units which causes the impossibility to boot the system. I also solved, by installing dbus-daemon-units, but as I explained above, atm, I cannot take the logs. So, to be sure and summarize: reinstall dbus-broker-units, reboot your computer, observe the failure and then get the logs from the last boot (if you can't switch to TTY like me, get the logs by using manjaro-chroot -a in a live USB of Manjaro).

[dvdhrm]

Can you figure out what provides /etc/dbus-1/system.d/org.manjaro.pamac.daemon1.conf (pacman -Qo <path>)? And can you post its content? According to your screenshot the configuration is invalid.

[rgudwin]

This problem happened to me, too. It is critical, as dbus is not properly started, you became with a non-tty console, without the possibility even to log in to the system. This is happening because the new dbus-broker is not resilient enough to deal with non-XML configuration files in /etc/dbus-1/system.d, probably installed by old packages, and does not start. The problem is everything else depends on dbus, even the services for tty login. The maintainers of this package should change their code to just make a warning (i.e. to ignore those non-compliant conf files) instead of aborting the start of dbus ... otherwise the whole system will be blocked. It took me a whole day to discover that and fix my system. I had to boot with a live pendrive, do a chroot and just move these files with non-XML confs at the system.d folder to a different location (possibly making the packages using them non-operative). Alternatively, if you can localize these old packages with non-XML conf files, you can also uninstall them. But dbus-broker should be more resilient to that. Dbus is a too important service to just die like that because of these non-XML configuration files.

[MR-Diamond]

the new dbus-broker is not resilient enough to deal with non-XML configuration files in /etc/dbus-1/system.d, probably installed by old packages, and does not start. [...] I had to boot with a live pendrive, do a chroot and just move these files with non-XML confs at the system.d folder to a different location (possibly making the packages using them non-operative). Alternatively, if you can localize these old packages with non-XML conf files, you can also uninstall them. But dbus-broker should be more resilient to that. Dbus is a too important service to just die like that because of these non-XML configuration files.

My content of ls -la /etc/dbus-1/system.d/ is:

-rw-r--r-- 1 root root  329 17 set  2019 gksu-polkit.conf
-rw-r--r-- 1 root root  899  1 ott 19.13 net.launchpad.backintime.serviceHelper.conf
-rw-r--r-- 1 root root 1470  5 set  2018 org.freedesktop.NetworkManager.Manjaro.conf
-rw-r--r-- 1 root root  891  2 dic 18.28 org.manjaro.pamac.daemon.conf

pacman -Qo on each file reports "No package owns $filename"

So: which files, exactly, did you removed from /etc/dbus-1/system.d/?

[rgudwin]

the new dbus-broker is not resilient enough to deal with non-XML configuration files in /etc/dbus-1/system.d, probably installed by old packages, and does not start. [...] I had to boot with a live pendrive, do a chroot and just move these files with non-XML confs at the system.d folder to a different location (possibly making the packages using them non-operative). Alternatively, if you can localize these old packages with non-XML conf files, you can also uninstall them. But dbus-broker should be more resilient to that. Dbus is a too important service to just die like that because of these non-XML configuration files.

My content of ls -la /etc/dbus-1/system.d/ is:

-rw-r--r-- 1 root root  329 17 set  2019 gksu-polkit.conf
-rw-r--r-- 1 root root  899  1 ott 19.13 net.launchpad.backintime.serviceHelper.conf
-rw-r--r-- 1 root root 1470  5 set  2018 org.freedesktop.NetworkManager.Manjaro.conf
-rw-r--r-- 1 root root  891  2 dic 18.28 org.manjaro.pamac.daemon.conf

pacman -Qo on each file reports "No package owns $filename"

So: which files, exactly, did you removed from /etc/dbus-1/system.d/?

In my case, it was the configuration file of an old package: panther-launcher-git ... to discover what is the offending configuration file, there are many options: you might look into each of them, trying to identify a non-XML file (a XML file is a text file and needs to start with a line like that: \<?xml version="1.0" encoding="UTF-8"\?> ... you can use "cat" or "less" to see them ... if your file does not start like that, you found your guilty file), or you can go strictly to the one is offending dbus-broker. If your boot is using a "quiet" directive, you need to take it off (to do that, you need to edit the /etc/default/grub and find the line starting with GRUB_CMDLINE_LINUX_DEFAULT= and remove the "quiet" from the list .. after that you need to do an "update-grub" and reboot) ... then the boot will show you the messages during the initialization of each service and you will get a message like the "Invalid XML in ..." that will show the exact configuration file that is disturbing dbus-broker. This is the one you need to move away.

[MR-Diamond]

Can you figure out what provides /etc/dbus-1/system.d/org.manjaro.pamac.daemon1.conf (pacman -Qo <path>)? And can you post its content? According to your screenshot the configuration is invalid.

@rgudwin Do you have this file? I have this as well and I checked: is a valid XML file.

I also checked with pacman -Qo, but is not owned by any package

@dvdhrm The content of '/etc/dbus-1/system.d/org.manjaro.pamac.daemon.conf' is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <!-- Only root can own the service -->
  <policy user="root">
    <allow own="org.manjaro.pamac.daemon"/>
  </policy>

  <!-- Allow anyone to invoke methods on the interfaces -->
  <policy context="default">
    <allow send_destination="org.manjaro.pamac.daemon"
           send_interface="org.manjaro.pamac.daemon"/>

    <allow send_destination="org.manjaro.pamac.daemon"
           send_interface="org.freedesktop.DBus.Introspectable"/>
    <allow send_destination="org.manjaro.pamac.daemon"
           send_interface="org.freedesktop.DBus.Peer"/>
    <allow send_destination="org.manjaro.pamac.daemon"
           send_interface="org.freedesktop.DBus.Properties"/>
  </policy>
</busconfig>

EDIT: I realized that the file is org.manjaro.pamac.daemon1.conf, with "1" in the name. However, I have two config files which aren't valid XML files. When I ended with my cuttent job/work, I'll remove them and I will also try to reinstall dbus-broker.

[rgudwin]

@MR-Diamond , your best bet is to check during boot which file is avoiding dbus-broker to start. Among other things I did while trying to solve the problem here, I enabled recovery mode in grub (it was disabled by default ... for that, you need to edit the /etc/default/grub and COMMENT the line with GRUB_DISABLE_RECOVERY=true, and then run "update-grub" from manjaro-chroot). It will create a recovery mode for booting (if you already have recovery mode you don't need to do that) ... while you boot in recovery mode, you will need to provide your root password, and you will gain a shell, in the middle of the boot process (still working, before the problem manifests). Then, in recovery mode, you can run "systemctl start dbus", and you will discover the file is causing the malfunction.

[MR-Diamond]

@dvdhrm @rgudwin @sileooo @teg

I solved, and I have to say a big thank you to rgudwin.

The files /etc/dbus-1/system.d/org.freedesktop.NetworkManager.Manjaro.conf and /etc/dbus-1/system.d/gksu-polkit.conf had an improper XML formatting: I fixed them (instead of removing) and I have been able to install dbus-broker without the issue on boot.

EDIT: /etc/dbus-1/system.d/org.freedesktop.NetworkManager.Manjaro.conf is owned by manjaro-hotfixes package. /etc/dbus-1/system.d/gksu-polkit.conf is owned by gksu-polkitpackage. Both packages are deprecated and obsolete, so I removed both. This removal has also deleted the mentioned conf files. But dbus-broker shouldn't break the boot process due to an improper XML formatting.

[dvdhrm]

Hey!

We believe allowing broken system software to be installed just leads to errors being ignored. In this case, there are clearly broken XML files, which somehow nobody fixed and thus will lead to some features clearly being broken in dependent tools.

Worst case, such scenarios will lead to D-Bus security policies being ignored, because the XML file cannot be parsed, and thus opening your system to security issues.

Our policy is to refuse broken system software to be installed. If you believe this to be wrong, you are welcome to open a separate issue and we can have a discussion about this. But please elaborate your stance and explain exactly what policy you would prefer.

I will close this issue as fixed, as the underlying issue was caused by broken XML files.

Thanks a lot for reporting it and showing how to fix it!

[Scimmia22]

Making the system unbootable seems a bit extreme, though, doesn't it? Surely there's some middle ground?

[luebking]

Our policy is to refuse broken system software to be installed.

That's like saying you're not gonna have safety-belts because you refuse to be involved in an accident. You're not in factual control of either.

The status quo is that if Joe User installs a single service w/ a malformed config, they'll be confronted with an unusable system that they'll have to analyze and fix offline, what is unrealistic and will drive the majority of them into bad decisions (uninformed mitigational efforts or re-installation)

The error is not critical to dbus-broker itself, so if the config is broken/malformed reject the specific service and carry on. Also most users will have some sort of notification daemon - spam them with warnings whenever it shows up on the bus.

[Scimmia22]

Even put in a 20 second delay or something to make sure they know something is wrong. Just bailing out completely seems like a massive overreaction.

[dvdhrm]

You are very much welcome to disagree. As I said before, if you are interested in discussing alternative approaches, please open a separate issue, elaborate your stance, compare it to the status quo and evaluate the pros and cons.