gui-apps/waybar-0.9.19 Unable to connect to the SYSTEM Bus

[necrosrc]

Hi! Does anyone have the same issue with the newest waybar version? 0.9.17-r3 version works ok.
The thing is, modules 'network' 'cpu' 'memory' 'temperature' 'clock' do not load because somehow there's no connection to system bus, i emerged 0.9.17-r3 version and somehow everything works.

gui-apps/waybar-0.9.19 output

Code: Select all

[2023-07-09 15:50:40.524] [info] Using configuration file /home/sourcerer/.config/waybar/config
[2023-07-09 15:50:40.524] [info] Using CSS file /home/sourcerer/.config/waybar/style.css
[2023-07-09 15:50:40.545] [info] Hyprland IPC starting
[2023-07-09 15:50:40.547] [warning] Can't resolve nl80211 interface
[2023-07-09 15:50:40.548] [warning] module network: Disabling module "network", Unable to connect to the SYSTEM Bus!...
[2023-07-09 15:50:40.548] [warning] module cpu: Disabling module "cpu", Unable to connect to the SYSTEM Bus!...
[2023-07-09 15:50:40.548] [warning] module memory: Disabling module "memory", Unable to connect to the SYSTEM Bus!...
[2023-07-09 15:50:40.548] [warning] module temperature: Disabling module "temperature", Unable to connect to the SYSTEM Bus!...
[2023-07-09 15:50:40.550] [warning] module clock: Disabling module "clock", Unable to connect to the SYSTEM Bus!...
[2023-07-09 15:50:40.555] [warning] Requested height: 30 is less than the minimum height: 42 required by the modules
[2023-07-09 15:50:40.555] [info] Bar configured (width: 1920, height: 42) for output: DP-1

gui-apps/waybar-0.9.17-r3 output

Code: Select all

[2023-07-09 15:57:51.994] [info] Using configuration file /home/sourcerer/.config/waybar/config
[2023-07-09 15:57:51.994] [info] Using CSS file /home/sourcerer/.config/waybar/style.css
[2023-07-09 15:57:52.015] [info] Hyprland IPC starting
[2023-07-09 15:57:52.016] [warning] Can't resolve nl80211 interface
[2023-07-09 15:57:52.017] [warning] Waybar has been built without rfkill support.
[2023-07-09 15:57:52.017] [warning] As using a timezone, some format args may be missing as the date library haven't got a release since 2018.
[2023-07-09 15:57:52.126] [warning] Requested height: 30 is less than the minimum height: 42 required by the modules
[2023-07-09 15:57:52.126] [info] Bar configured (width: 1920, height: 42) for output: DP-1

[The Main Man]

Yeah, same here, had to mask latest version and downgrade to previous (0.19.17-r3)
Didn't had a chance to investigate what's that all about

[necrosrc]

Yeah, same here, had to mask latest version and downgrade to previous (0.19.17-r3)
Didn't had a chance to investigate what's that all about

Looks like i'm forced to do the same. Thank you for sharing, at least i'm not alone.
Kinda sad, because in this release they added fixes for hyprland.

Have a nice day!

[The Main Man]

Yeah indeed, I'm on Sway though, so I guess we can rule out the WM

I wonder why 0.9.18 was skipped, maybe the problem started with that one

[flexibeast]

i'm on 0.19.9 under Sway, and don't seem to be experiencing this issue.

i just downloaded and diff'd the 0.9.17 and 0.9.19 tarballs:

Code: Select all

$ diff -ur Waybar-0.9.17 Waybar-0.9.19 | grep '^\+\|^-' | grep -i dbus
grep: warning: stray \ before +
-    pacman -S --noconfirm git meson base-devel libinput wayland wayland-protocols pixman libxkbcommon mesa gtkmm3 jsoncpp pugixml scdoc libpulse libdbusmenu-gtk3 libmpdclient gobject-introspection libxkbcommon playerctl
+    pacman -S --noconfirm git meson base-devel libinput wayland wayland-protocols pixman libxkbcommon mesa gtkmm3 jsoncpp pugixml scdoc libpulse libdbusmenu-gtk3 libmpdclient gobject-introspection libxkbcommon playerctl && \
-    'pkgconfig(dbusmenu-gtk3-0.4)' 'pkgconfig(fmt)' 'pkgconfig(gdk-pixbuf-2.0)' \
+    'pkgconfig(dbusmenu-gtk3-0.4)' \
+#include "giomm/dbusproxy.h"
+  Glib::RefPtr<Gio::DBus::Proxy> login_proxy_;
+  login_proxy_ = Gio::DBus::Proxy::create_for_bus_sync(
+      Gio::DBus::BusType::BUS_TYPE_SYSTEM, "org.freedesktop.login1",
-    Gio::DBus::unwatch_name(bus_name_id_);
+    Gio::DBus::unown_name(bus_name_id_);

[The Main Man]

That is interesting, how do you start Sway ? Do you use maybe login manager ?

I do it via terminal after login :

Code: Select all

$ dbus-run-session sway

[flexibeast]

i login on the console, and a D-Bus session bus is started via ~/.zlogin:

Code: Select all

 echo -n "Starting D-Bus session bus ...."
dbus-daemon --session --fork --print-address 4 --print-pid 5 4>!~/.session-bus-address 5>!~/.session-bus-pid
echo " $(cat ~/.session-bus-pid)"
export DBUS_SESSION_BUS_ADDRESS="$(cat ~/.session-bus-address | tr -d '\n')"

i save the address in a file to make it available in other contexts: in particular, i read that file to set the value of DBUS_SESSION_BUS_ADDRESS in a warnings notifications script i run as a cron job.

i then run a 'startsway' script from the console; the above line in ~/.zlogin means that DBUS_SESSION_BUS_ADDRESS has been set in that environment and nothing more needs to be done.

However, that's all about the D-Bus session bus. The D-Bus system bus is a separate bus, and on my system, is started via the 'dbus' OpenRC service.

In other words: starting a session bus via e.g. 'dbus-start' or 'dbus-run-session' does not mean that the system bus has been started. i'd be interested to know if those having issues with Waybar can confirm that they have a running system bus.

[The Main Man]

I guess the problem is in the system bus, I only have session bus running, you have the system one as well, started with openrc service and I don't.
I'll probably check that later and test if that's the problem here, don't see what else could be.

[necrosrc]

I guess the problem is in the system bus, I only have session bus running, you have the system one as well, started with openrc service and I don't.
I'll probably check that later and test if that's the problem here, don't see what else could be.

Just in case, https://github.com/Alexays/Waybar/issues/2297

Someone opened issue, but still no replies.

Have a nice day!

[flexibeast]

I guess the problem is in the system bus, I only have session bus running, you have the system one as well, started with openrc service and I don't.
I'll probably check that later and test if that's the problem here, don't see what else could be.

Just in case, https://github.com/Alexays/Waybar/issues/2297

Someone opened issue, but still no replies.

Well, do you have a D-Bus system bus, whether under systemd or OpenRC, running on your system? One way to check would be to run:

Code: Select all

$ pgrep -a dbus-daemon

A system bus will show up as an instance of `dbus-daemon` with a `--system` argument.

[Anon-E-moose]

I have dbus --system running on my mach, mainly because I was playing with bluez and a touchpad, and bluez requires dbus system to work properly with battery reporting.

There are a few modules in waybar that do require dbus system, the sni module (tray), the backlight, and other reporting module, basically anything that requires system level access to get data.

Code: Select all

 497 ?        /usr/bin/dbus-daemon --system
 8494 tty1          \_ dbus-run-session -- /usr/bin/Hyprland

If you have dbus installed for whatever reason, there's no big deal about running dbus system, just put /etc/init.d/dbus in the default run level.

Edit to add: There have been some merges that might be causing the problem for modules that don't require dbus, I haven't looked at all of them yet.
I haven't looked at the latest documentation to see if dbus is required for all of waybar.

[CooSee]

i'm on 0.19.9 under Sway, and don't seem to be experiencing this issue.

no issues with sway, too.

using a mix with *-9999 ebuilds - downgraded waybar to 0.19.9 on openrc system with xwayland disabled.

after sway emerge or upgrade - i always edit the following and add dbus-run-session <<< it's the same for hyprland

cat /usr/share/wayland-sessions/sway.desktop

Code: Select all

[Desktop Entry]
Name=Sway
Comment=An i3-compatible Wayland compositor
Exec=dbus-run-session sway
Type=Application

i start waybar via script, because i had issues which waybar doesn't start after first time login, but on reload via mod+shift+c.

that is why added a little delay in script.

from my sway config

Code: Select all

 # Bar
exec_always --no-startup-id $HOME/.config/waybar/waybar.sh

~$HOME/.config/waybar/waybar.sh

Code: Select all

#!/usr/bin/env sh
# Terminate already running bar instances
killall -q "waybar"

# Wait until the processes have been shut down
while pgrep -x waybar >/dev/null; do sleep 3; done

# Launch main
sleep 2; waybar -c $HOME/.config/waybar/config -s $HOME/.config/waybar/style.css

will try with hyprland at later time and report

i hope this will help some of you.

[The Main Man]

So, what you're saying is that you're running latest version without dbus system, am I right ?

[CooSee]

So, what you're saying is that you're running latest version without dbus system, am I right ?

what ? - but, dbus is necessary >>> interprocess communication (IPC) system for software applications

here's an old *.log when i start sway without the dbus-run-session in

Code: Select all

Session: /usr/share/wayland-sessions/sway.desktop
Desktop: sway
Exec:    sway
---
amdgpu: amdgpu_cs_ctx_create2 failed. (-13)
2023-03-10 17:17:04 - [swaybg-9999/main.c:293] Found config * for output HDMI-A-1 (Iiyama North America PL2773H 0)
2023-03-10 17:17:04 - [swaybg-9999/main.c:293] Found config * for output HDMI-A-2 (BNQ BenQ GW2265 C9E07436019)
[2023-03-10 17:17:04.339] [info] Using configuration file /home/myuser/.config/waybar/config
[2023-03-10 17:17:04.340] [info] Using CSS file /home/myuser/.config/waybar/style.css
Could not aquire notification name. Please close any other notification daemon like mako or dunst
Could not connect to CC service. Will wait for connection...
[2023-03-10 17:17:04.718] [info] Bar configured (width: 1920, height: 29) for output: HDMI-A-1

i just confirmed that there's no issue with sway and current released waybar.

[The Main Man]

You misunderstood, there are two ways you can run D-Bus, system bus or session bus.
What is the output of

Code: Select all

$ pgrep -a dbus-daemon

when you run it ?

[CooSee]

pgrep -a dbus-daemon

Code: Select all

2052 /usr/bin/dbus-daemon --system
2708 dbus-daemon --nofork --print-address 4 --session
2853 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/run/user/1000/at-spi/bus

[The Main Man]

Right, so you have it running as a system

We already established earlier that it's working with system dbus, problem is with the session dbus.
That's new in the latest version.

[CooSee]

Right, so you have it running as a system

We already established earlier that it's working with system dbus, problem is with the session dbus.
That's new in the latest version.

i see! - misread again.

this happens more often nowadays, because i'am getting older everyday

[The Main Man]

It happens

Although there's no harm in running system dbus, I never had to run it, until now, which is weird that this package requires it.
I'll either patch the latest version and have that part removed, or just enable the service running from now on, I'll think about it

[Anon-E-moose]

Not sure if this fixes it, but this was released just after the 9.19 release.

Code: Select all

diff --git a/src/util/prepare_for_sleep.cpp b/src/util/prepare_for_sleep.cpp
index 221497e8..218c1e29 100644
--- a/src/util/prepare_for_sleep.cpp
+++ b/src/util/prepare_for_sleep.cpp
@@ -1,6 +1,7 @@
 #include "util/prepare_for_sleep.h"
 
 #include <gio/gio.h>
+#include <spdlog/spdlog.h>
 
 namespace {
 class PrepareForSleep {
@@ -9,7 +10,7 @@ class PrepareForSleep {
     GError *error = NULL;
     login1_connection = g_bus_get_sync(G_BUS_TYPE_SYSTEM, NULL, &error);
     if (!login1_connection) {
-      throw std::runtime_error("Unable to connect to the SYSTEM Bus!...");
+      spdlog::warn("Unable to connect to the SYSTEM Bus!...");
     } else {
       login1_id = g_dbus_connection_signal_subscribe(
           login1_connection, "org.freedesktop.login1", "org.freedesktop.login1.Manager",
-- 

If someone wants to see if this fixes the problem put the above in /etc/patches/gui-apps/waybar-0.9.19 and emerge waybar
OR use the 9999 version (would apply this but might have other problems)
OR just wait for the next version


Though I'm scratching my head as to why everything is going through code for sleep/wake when many will never use that functionality.

[necrosrc]

I have dbus --system running on my mach, mainly because I was playing with bluez and a touchpad, and bluez requires dbus system to work properly with battery reporting.

There are a few modules in waybar that do require dbus system, the sni module (tray), the backlight, and other reporting module, basically anything that requires system level access to get data.

Code: Select all

 497 ?        /usr/bin/dbus-daemon --system
 8494 tty1          \_ dbus-run-session -- /usr/bin/Hyprland

If you have dbus installed for whatever reason, there's no big deal about running dbus system, just put /etc/init.d/dbus in the default run level.

Edit to add: There have been some merges that might be causing the problem for modules that don't require dbus, I haven't looked at all of them yet.
I haven't looked at the latest documentation to see if dbus is required for all of waybar.

Thank you guys. So, i gave up and added dbus to default run level and worked...
https://wiki.gentoo.org/wiki/D-Bus#OpenRC

Maybe i should look for something else than waybar, but for now i will leave this system bus running.
This is the first time ever i needed system bus, and i swear i didnt know

[The Main Man]

Not sure if this fixes it, but this was released just after the 9.19 release.

Works, thanks for this!

Indeed, makes no sense for the main code to even go inside this part of the code if it's not used at all.

btw it's /etc/portage/patches/gui-apps/waybar-0.9.19