I am also experiencing this with Waybar v0.10.3 and Sway. I was hesitating reporting before I had a concrete reproducible but I didn't yet figure how to trigger this behaviour.

For now I can only confirm that:

• there is one Waybar process running at all times
• sending a SIGUSR2 to Waybar kills them but after another DPMS off -> on they're all back
• the number of Waybars grows randomly up to 7 (why 7?) they seem to grow without limit
• sending a SIGKILL and restarting Waybar of course wipes everything until it grows back to 7
• in my case, these duplicated Waybar GTK windows only seem to appear on the external monitor

By looking at the Waybar code, I am not sure where it happens. Could be even GTK receiving a wrong input on the onConfigure event. Next time I will debug this with GTK_DEBUG=all killall -SIGUSR2 waybar. I sense that I will see more Gtk_Window instances than expected.

I've had this for a long time, now. I'm on Hyprland. I was not certain of the cause and whether it was a Waybar issue or a Hyprland issue. Its one of those things I kept telling myself I'd look into but never made time for it since I'd usually just restart waybar.service... seeing some of the preliminary findings is motivating, though.

I could catch this happening with waybar debug logging but unfortunately nothing interesting came out:

First, correct configuration when plugging the external monitor (HDMI-A-2)

[2024-06-19 10:08:07.596] [info] Bar configured (width: 1920, height: 33) for output: eDP-1
[2024-06-19 10:08:07.597] [info] Bar configured (width: 2560, height: 33) for output: HDMI-A-2

Then, correct reconfiguration when unplugging the external monitor:

[2024-06-19 18:27:36.312] [info] Bar removed from output: HDMI-A-2

Then, after waking up from the standby, I see 3 (!) instances of the previous monitor being removed

[2024-06-19 18:27:36.299] [debug] Output removed: Dell Inc. DELL U2515H
[2024-06-19 18:27:36.299] [debug] Output removed: Dell Inc. DELL U2515H
[2024-06-19 18:27:36.299] [debug] Output removed: Dell Inc. DELL U2515H
[2024-06-19 18:27:36.312] [info] Bar removed from output: HDMI-A-2

Relevant code where this is handled.

and finally when plugging the new monitor, 3 instances are configured in a short burst:

[2024-06-19 19:18:29.161] [debug] Output detection done: HDMI-A-2 (WOR TERRA LED2211 22129TB000514)
[2024-06-19 19:18:29.171] [warning] Mapping is not an object
...
[2024-06-19 19:18:29.286] [debug] Output detection done: HDMI-A-2 (WOR TERRA LED2211 22129TB000514)
[2024-06-19 19:18:29.287] [warning] Mapping is not an object
[2024-06-19 19:18:29.340] [debug] Output detection done: HDMI-A-2 (WOR TERRA LED2211 22129TB000514)
[2024-06-19 19:18:29.341] [warning] Mapping is not an object
...
[2024-06-19 19:18:29.831] [info] Bar configured (width: 1920, height: 33) for output: HDMI-A-2
[2024-06-19 19:18:29.831] [info] Bar configured (width: 1920, height: 33) for output: HDMI-A-2
[2024-06-19 19:18:29.831] [info] Bar configured (width: 1920, height: 33) for output: HDMI-A-2

As expected the GTK debug show 3 windows:

I have no clue about what is happening here 🤷‍♂️

cc @Alexays any insights?

I am testing the gtk4 branch now. Will keep you updated and provide logs.

I get this on the gtk4 branch. I just woke from sleep (dpms off) and now have two bars. FYI - I was away from my workstation all last week which is why I didn't report the issue sooner.

Maybe also of interest: I have 2 4K monitors. I regularly switch from two to one and back again. I use a small script to do this: it rewrites monitors.conf, moves windows and workspaces around (using hyprctl monitor, hyprctl dispatch workspace and hyprctl dispatch moveworkspacetomonitor and uses ddcutil to switch monitor inputs.

I don't see a pattern with this issue and the monitor switching, only with the sleep. Just mentioning in case it's of any use.

I have two 2k monitors and I don't do any switches but I'm facing same issue. Using with hyprland.

➜  ~ expac '%-30n %v' -s 'waybar|hyprland|hypridle|hyprlock'
grimblast-git                  r89.fe26a90-1
hyprcursor                     0.1.9-1.1
hypridle                       0.1.2-1.1
hyprland                       0.41.2-1
hyprlock                       0.3.0-1.1
hyprutils                      0.1.5-1.1
nwg-panel                      0.9.34-1
waybar                         0.10.3-1.1
xdg-desktop-portal-hyprland    1.3.2-1.2

It's pretty consistent, happens everytime when it wakes up from dpms off state. As similar, pkill -SIGUSR2 waybar fixes it but yeah it's not a good experience though.

Helllo fellow hyprland and waybar users...

Is there anything I can do to help troubleshoot / resolve this? It's starting to get a little irritating. Every time I leave my workstation for more than a few minutes, I come back to a waybar-nado and have to pkill -SIGUSR2 waybar.

As a workaround, I tried adding the following to my hypridle config but it seems to not work:

listener {
    timeout = 900
    on-timeout = hyprctl dispatch dpms off  # command to run when timeout has passed
    on-resume =  hyprctl dispatch dpms on && pkill -SIGUSR2 waybar  # command to run when activity is detected after timeout has fired.
}

Maybe the pkill is running before we see the issue.

I guess swayidle would show the same problem.

However, if I do the following I am not able to replicate the problem:

sleep 3; hyprctl dispatch dpms off; sleep 10 ; hyprctl dispatch dpms on

Anyone have any insight or ideas on either a workaround or how to deterministically replicate the issue?

Thank you

I may found a workaround by luck, yesterday I was trying some config changes and instead of restarting waybar using SIGUSR2 I did a killall and started using:

hyprctl dispatch exec "waybar -c ~/.config/waybar/config-hypr"

Today my monitors went off couple of times and this bug didn't happen. Will test further

I have the same issue in River

Having this, too. But I think restarting by SIGUSR2 is not a workaround, it's actually triggering the duplication. In sway, if I do

killall -SIGUSR2 waybar; swaymsg output DP-1 disable; sleep 1; swaymsg output DP-1 enable

Then after the screen is re-enabled, waybar comes back with itself duplicated. After many times running the command, waybar will then duplicate as many times.

Having this, too. But I think restarting by SIGUSR2 is not a workaround, it's actually triggering the duplication.

That's a good catch. I'm finally able to reproduce the issue with your command, and SIGUSR2 indeed was the problem.

The handler for SIGUSR2 is a mess: it causes a complete reinit of the application (waybar::Client::main()) over an existing state. Every time that happens we register a new set of Gdk::Display::signal_monitor_added()/Gdk::Display::signal_monitor_removed() handlers and receive more and more duplicate events for the same monitor.

I'll need some time to figure out how to untangle that properly (and address the obvious signal safety violations in main.cpp). A quick and dirty patch is available here: alebastr@reload-signal-fix

Functionally, SIGUSR2 isn't different from restarting the application, so I suggest to just stop using it for now.

I removed the SIGUSR2 signals from my ~/.config/systemd/user/waybar.service and ~/.config/hypr/hypridle.confm and I have re-introduced all of the previous dpms off and dpms on config in hypridle.conf.

I am now unable to replicate the issue. I have not seen it again since those config changes a few days ago.

Looks good to me!