[Bug] Waybar silently does not start Hyprland IPC

[rhelder]

Description of bug

Sometimes, on login, Waybar's Hyprland workspaces module does not work as expected. Waybar displays active workspace 1, but then never changes when I switch to a new workspace or new workspaces are added. So if workspace 2 is currently active, for example, Waybar still shows that workspace 1 is active, and it does not show that workspace 2 exists.

This same behavior was reported in #3627, but the user closed the issue because they were not able to reproduce the bug.

Steps to Reproduce

I can only reproduce the bug on login. (Note: I use uwsm to start Hyprland, and I preface it with exec to tell uwsm to replace my login shell, as is recommended. So when I say that I can only reproduce the bug on login, for me that's the same as saying that I can only reproduce the bug on compositor startup. I think that you could reproduce the issue just by restarting the compositor, without logging out, but I haven't tested that.) And I can always fix the bug just by restarting Waybar. So the issue only occurs when Waybar and Hyprland are both starting up.

How you start Waybar during Hyprland start up makes no difference. I was able to reproduce the issue using a custom systemd unit, with the systemd unit packaged with Waybar, using exec-once = exec uwsm app -- waybar in hyprland.conf, and using exec-once = waybar in hyprland.conf.

Other than that, the issue occurs more or less at random. The only way to reproduce the issue is to log in and out repeatedly until it happens (or reboot, or whatever. But that's not very fast for testing). I am usually able to reproduce the issue in fewer than 10 attempts. Sometimes I wasn't able to reproduce the issue after even as many as 30 attempts, though (only to discover later that I could reproduce the issue with the same setup). It definitely happens often enough in real life to be a real nuisance.

I was able to reproduce this issue using only the following minimal config (plus the style file packaged with Waybar, since I didn't provide a user style file):

// -*- mode: jsonc -*-
{
  "modules-left": [
    "hyprland/workspaces"
  ]
}

I used the latest versions of Waybar and Hyprland when reproducing the issue:

• Waybar: 0.13.0
• Hyprland: 0.49.0

And I am using the packages provided by the Arch Linux Extra repository:

• waybar 0.13.0-3
• hyprland 0.49.0-3

Diagnostics

To generate logs, I modified the packaged systemd unit so that Waybar was executed with the -l trace option. Then full debugging information is just written to the systemd journal.

Waybar does not throw any errors when the issue occurs. What I've observed, however, is that every time the hyprland/workspaces module is started up correctly, Waybar says 'Starting Hyprland IPC...', and that every time the hyprland/workspaces module is not started up correcty, Waybar does not say 'Starting Hyprland IPC...'. Moreover, when the hyprland/workspaces module is started up correctly, it prints the expected 'hyprland IPC received' messages, 'Creating workspace' messages, and so on. When the hyprland/workspaces module is not started up correctly, it prints none of these messages, even though I am actually creating and changing workspaces.

Here is one log of journal messages when the hyprland/workspaces module is acting normally, and another log of the journal messages when the module is not acting normally. I've omitted the timestamps so that you can diff them easily. If you do diff them, you'll see a nice visual representation of what I said in the last paragraph.

normal.log
bugged.log

I didn't find any useful additional information in dmesg logs.

So, in sum, the logs and steps to reproduce indicate that sometimes, at login, Waybar will (silently) not start listening to Hyprland's sockets, and that's why Waybar won't make new workspaces, change the active workspace, and so on.

Waybar or Hyprland?

I don't have the background knowledge to be able to say for sure, but I think the bug is Waybar's, and not Hyprland's. I was able to confirm in my testing that I can reproduce the bug even when both of Hyprland's sockets already exist. The way I did this was by writing a script to check for the existence of both of Hyprland's sockets. The script 'fails' if they are not found after 5 seconds. I added an ExecStartPre calling the script to Waybar's systemd unit, which means that Waybar is executed only if the script has been executed successfuly -- or, in other words, that Waybar is only executed if both of Hyprland's sockets exist. Even with this modification to the systemd unit, I was able to reproduce the issue. Again, I don't have the background knowledge, but if Hyprland's sockets are available, it seems like Waybar should be able to read them. So that's why I'm thinking for now that the problem is not on the sending end (because the sockets exist), but rather on the receiving end.

Thanks very much for your work on Waybar, and I hope this bug report can be helpful!

[corigne]

I can confirm this bug exists for me as well.

I usually update on a regular basis. As the bug doesn't always happen, I'm not sure what caused it or exactly when. I clued into it about a week to two weeks ago. It is happening both on my laptop and desktop, which have similar configurations.

Additional Info:

• hyprland version: 0.49.0-3
• waybar version: 0.13.0-3

Some time ago (5-6 months I think?) I switched to uwsm.
My hyprland config kicks off waybar using the following exec-once:

exec-once = uwsm app -- waybar &

Waybar configuration attached below.

config.jsonc

[corigne]

Following up, Waybar workspace module was working on session start and is now not working. The laptop has not been put into idle/sleep/standby during the last 12 hours while on AC power. Waybar hasn't logged anything useful.

[lfos]

Possibly related to #3975.

@corigne - At least the issue described in your last comment is likley #3975 instead of the original issue described here. The difference is that in #3975, IPC works at start and if you run with -l trace, you'll see that IPC messages are still received but not processed properly.

[pzread]

I ran into a similar issue (also using uwsm app -- waybar) and found that #4359 might be related. I tried that patch and it seems to fix the issue for me

I think the issue is this check in the IPC thread

Waybar/src/modules/hyprland/backend.cpp

Line 81 in 41de896

if (!modulesReady) return;

is racing with other moduleReady = true, for example in the workspace module

Waybar/src/modules/hyprland/workspaces.cpp

Line 22 in 41de896

modulesReady = true;

And the PR above fixed the race condition