Open Swexti opened 2 years ago
What command are you using to run eww?
If you use the —config </path/to/config>
option then you have to redeclare it any time you want to contact the eww daemon started at runtime.
The correct command to kill an eww window in that case would be /path/to/eww —config /path/to/config/ kill
.
It’s odd behavior for sure, and results in some whacky configuration issues. In several examples updating a variable requires the update var=value
portion of the command to be concatenated with a global command variable.
What command are you using to run eww?
Just the normal eww open <window name>
, I'm not using any config location flag, no.
I have the same issue - Except for that my issue happens to start a new instance of eww that i can run eww kill
on, but the "old" instance is still open which doesn't respond to any commands from eww. The only way to close it so far is to run the likes of pkill eww
and then starting the daemon again.
I'm getting the error
INFO eww::app > Opening window dashboard
ERROR eww::error_handling_ctx > sending response from main thread
Caused by:
0: Failed to send success response from application thread
1: channel closed
EDIT: The error does not always open a new instance, but it does quite frequently
I'm having the same issue that @madser123 described, i ran some tests on my own and for me this error starts happening when opening ~4+ (empty) windows using open-many
. Though others are having the same issue with just a single window, so perhaps it has something to do with the time it takes to load the window(s).
I mentionned the same issue in [BUG] Eww spawns zombie windows and processes #255 .
Normally when a daemon is running eww open bar
should not open a new process. But after some time it seems to loose sight of the daemon. So now I use a script to check if a process is running for the open command, in which case I kill everything and open a new daemon.
#!/usr/bin/env bash
# locale
LC_ALL="C.UTF-8"
TZ=:/etc/localtime
Help()
{
echo "This script launch Eww or a window in daemon mode & it can toggle or kill it all too."
echo
echo "Syntax: ./eww.sh [-h] [-w \"<window_title>\"] [-k]"
echo "options:"
echo "-h Print this Help"
echo "-w \"<window_title>\" Fixed terminal title"
echo "-k kill the daemon"
echo
}
while getopts ":hw:k" option; do
case $option in
h ) Help
exit 0 ;;
w ) _windowTitle="${OPTARG}" ;;
k ) eww kill
killall eww
exit 0 ;;
\?) echo -e "Unknown option: -$OPTARG \n" >&2; Help; exit 1;;
: ) echo -e "Missing argument for -$OPTARG \n" >&2; Help; exit 1;;
* ) echo -e "Unimplemented option: -$option \n" >&2; Help; exit 1;;
esac
done
if [[ -z $_windowTitle ]]; then
echo -e "Error: option -w is mandatory. \n" >&2; Help; exit 1
fi
if pgrep -f "eww open $_windowTitle"; then
# Eww window is running outside of a daemon
killall eww
eww daemon
sleep 2
eww open $_windowTitle
elif pgrep -f "eww daemon"; then
# Eww Daemon is running
if [[ "$(eww state)" == "" ]]; then
# no window running currently
eww open $_windowTitle
else
eww close-all
fi
else
# Eww Daemon not running
killall eww
eww daemon
sleep 2
eww open $_windowTitle
fi
I have a similar problem.
It seems to be caused by firing 'eww open' too quickly. i.e. the command needs de-bouncing.
I have the daemon running via systemd I have a button on waybar which runs 'eww open-many menu menu-closer'
If I double-click, then I end up with the widgets stuck on the screen and nothing can fix it. the daemon seems to end up a bit deaf and out of sync with what windows are really open.
My actual user-scenario is a touch-screen, and it seems that sometimes the touch can be picked up as some rapid clicks. So I will try to de-bounce it somehow. but at least this might help you get to the bottom of the problem.
No, sorry I was wrong. Although I can break it very quickly by double-clicking my waybar button, and I have now put together a bash script to de-bounce/refuse to run 'eww open' if such a process & cmdline already exists, I still have the same problem. After a few iterations off 'eww open-many --toggle menu menu-closer', I end up where the 'eww open' actually fires up another daemon and things are just broken and stuck on the screen. Happens every time within a few goes,
Somehow, using --no-daemonize when calling 'open-many --toggle', seems to avoid the problem. Not sure why. I have the daemon running under systemd as a simple unit (with "daemon --no-daemonize")
I haven't been able to reproduce this ever. However, I tried to potentially fix this by making eww try a bit harder to reconnect to existing daemons when starting up. Could you try out the fix-dangling-daemon
branch at some point and see if that improves it? if it doesn't, it'd be interesting to see the logs, specifically with --debug
enabled
I've run into this problem too, I'm not sure if it will help, but in my case I set the initial parameter for all the defpoll variables to fix it.
I found that this bug appears more often on my old PC, so I did an experiment: create a really slow virtual machine (512 MB RAM and only 30% from one CPU core), and now bug is stable. Looks like when Eww trying to open a window, and something (system or another app) get machine resources, Eww just abandones current window and trying to open another one - sometimes again and again and again. As a result, only the last window may be managed.
Eww compiled from fix-dangling-daemon
branch shows this error when I trying to close window (window stay opened and don't response):
2023-05-16T16:17:51.597Z ERROR eww::error_handling_ctx > Error while forwarding command to server
Caused by:
0: Failed to send command size header to IPC stream
1: Broken pipe (os error 32)
I found that this bug appears more often on my old PC, so I did an experiment: create a really slow virtual machine (512 MB RAM and only 30% from one CPU core), and now bug is stable. Looks like when Eww trying to open a window, and something (system or another app) get machine resources, Eww just abandones current window and trying to open another one - sometimes again and again and again. As a result, only the last window may be managed.
Eww compiled from
fix-dangling-daemon
branch shows this error when I trying to close window (window stay opened and don't response):2023-05-16T16:17:51.597Z ERROR eww::error_handling_ctx > Error while forwarding command to server Caused by: 0: Failed to send command size header to IPC stream 1: Broken pipe (os error 32)
That makes sense. My systems are using Rock 4C SBCs (like Raspberry Pi 4), so they are slow compared to a typical PC. I was able to replicate the problem every time by getting bash to repeat the command ~10 times as quickly as it could.
I got this same problem whereby eww seems to hang and I see "Failed to send success response from application thread" when this happens.
I don't think the speed of the machine is a factor. And I don't have to mash the mouse button to make eww open/close quickly, as even a 2-3 second pause between toggling the widgets on and off triggers this bug.
I'm running eww 0.4.0 (built from source) on both a Ubuntu 23.04 laptop with i7-10750H Processor 2.6 GHz, and VMWare Ubuntu 23.04 running on a Dell Latitude 5521. My WM is bspwm 0.9.10 with picom v9.1 compositor. Have been seeing this issue for some time - even back when I was running Ubuntu 22.10 some months ago.
Very consistently reproducible after a few eww open-many / eww close-all calls on both my Ubuntu laptop and VM.
My setup is essentially a copy of https://github.com/adi1090x/widgets/tree/main/eww/dashboard but with minor edits of the scripts to get them working on Ubuntu + youtube-music (playerctl instead of mpc).
Interestingly, this tends to happen when I try toggling the eww bars off (eww --config ... close ...
). The bars get stuck on screen, and I can see the eww --config ... open-many ...
process is no longer running although the eww --config ... daemon
process is still running. And trying to talk to the existing daemon (eww --config ... close-all ...
) yields an error and appears to try to start a new daemon:
2023-06-09T07:36:48.581Z WARN eww > Failed to connect to daemon: Error while forwarding command to server
2023-06-09T07:36:48.581Z INFO eww > Initializing eww server. (/run/user/1005/eww-server_585055dd4af31ee7)
And despite saying it is initialising a new (presumably daemon) server I can still see the old hung daemon but no new one:
# ps -ef|grep eww
amplexus 3393535 1 4 17:36 ? 00:00:04 /usr/local/bin/eww --config /home/amplexus/.config/bspwm/rices/kahzia/dashboard daemon
same problem ,Is there any progress on this issue?
I had this problem, I don't know why but when I use the eww bin from target/release
it works perfectly, but when I move it to my ./local/bin
folder the bug comes back. Should I move another files to this folder? ( I don't have idea what I'm doing)
This issue does not occur when I install it by using yay in arch, it only occurs when I manually build source code in ubuntu.
fyi if you are spawning eww daemon
and eww open x
at the same time (even when the daemon is initialized e.g. eww daemon && eww open x
) then you run into this (got this in my hyprland config on acccident)
Checklist before submitting an issue
Description of the bug
Eww does not close sometimes, not sure why It happens, but I believe it is randomly. Running
eww kill
does also not close eww, and I am forced to end eww within htop.Log:
But, eww stays open, and I have to end it with htop. It does not happen every time, but most of the time.
Reproducing the issue
No idea, honestly, seems to only happen with that specific config. Trying the bar example config runs fine, and eww can close properly every time. So I'd bet writing a new config here for a reproduction would likely result in the config working fine.
Expected behaviour
Close the widget. That's about as detailed as it gets.
Additional context
This does not affect functionality, from what I know. Changing windowtype or stacking also does not affect it.