-
-
Notifications
You must be signed in to change notification settings - Fork 724
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
waybar keeps eating my CPU #2631
Comments
I believe I'm affected by the same issue which is caused by last commit squeezed in before release: #2629. It adds reaping of child command process to the main Waybar/include/util/command.hpp Lines 115 to 117 in c6a9b63
ignoring the fact that it's already being reaped through close: Line 71 in c6a9b63
Waybar/include/util/command.hpp Lines 44 to 67 in c6a9b63
Both of these now race as to who will be the first to successfully
I would revert 1c1a39f possibly followed by improving |
Same here but it's eating all my CPU 🔥 |
100% of a core gets eaten up by waybar on my machine too.
EDIT: as per other comments, disabling all the custom ones works around the problem |
same issues by latest commit |
Same problem for me since upgrading to Waybar v0.9.23 (installed via the Arch Linux respositories), 100% load on one CPU core. Log Level Debug does not seem to make any difference for me. After some trial and error I found out that the CPU load is normal without a custom module, which I am using:
Not sure if the configuration is correct, I can only say that the module works fine after a downgrade to Waybar v0.9.22. |
Same here, any custom module that uses terminal commands makes one of CPU cores always run at 100%. Downgrading to 0.9.22 fixes it, too bad persistent workspaces are broken in 0.9.22... |
Not a "+1" fan, but |
The same problem. It eats up to 300% of my CPU cores. But when I remove my custom modules, it works normally. |
Same here! |
@Alexays issue remains after reverting bf371f7 but that was kind of expected. The actual issue was already bisected and explained (#2631 (comment)) or you don't agree with this analysis? |
Yep I can totally confirm this too. on 0.9.22 Waybar seems to use a decently normal amount of cpu On waybar 0.9.23, however, it starts at ~20% cpu usage and keeps rising. I can also confirm that starting with Also, on 0.9.23 the media player modules I previously mentioned appear weird, where some of them appear and others don't on some monitors. My configuration can be found here: https://github.com/alba4k/.dotfiles/tree/master/.config/waybar |
Here is a perf of 9.23.0 release:
|
Released 0.9.24 with the faulty commit reverted. |
now i finally understand what you were saying 💀 thank you for your help :) |
OMG! My fan has been spinning all day. 🔥 |
Version: Waybar v0.9.22-215-g7dfc7200 (branch 'master')
Installed with the AUR package waybar-git
Distro: EndeavourOS
Kernel: 6.5.9-arch2-1
WM/DE: Hyprland
Basically if I run waybar normally, it will eat ~16% of my CPU,
but if I run it with the "-l debug" option, it runs normal and doesn't eat CPU at all.Tested on Hyprland, commit 062f749Edit:
this bug is strange, basically when I terminated the
waybar
process and then runwaybar -l debug
, it used to run waybar normal but it happens that will eat the same amount of CPU as when running normally, continuing to spam[2023-11-02 15:07:42.326] [debug] waitpid failed: No child processes
The text was updated successfully, but these errors were encountered: