[BUG] Eww does not close sometimes, even when running `eww kill`

[Swexti]

Checklist before submitting an issue

• [X] I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
• [X] I have specifically verified that this bug is not a common user error
• [X] I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

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:

┏━━━━━━━━━━━━━━━━━━━━━━━┓
┃Initializing eww daemon┃
┗━━━━━━━━━━━━━━━━━━━━━━━┛

(eww:8579): GLib-GObject-WARNING **: 15:25:47.271: ../../../gobject/gsignal.c:2736: instance '0x564dc471c500' has no handler with id '923'
 2022-05-02T13:25:47.304Z ERROR eww::error_handling_ctx > sending response from main thread

Caused by:
    0: Failed to send success response from application thread
    1: channel closed
 2022-05-02T13:25:47.380Z INFO  eww::app    > Opening window widget
 2022-05-02T13:25:47.381Z INFO  eww::ipc_server > IPC server initialized
Action failed with error: Tried to close window named 'widget', but no such window was open
Action failed with error: Tried to close window named 'widget', but no such window was open
 2022-05-02T13:26:06.196Z INFO  eww::server             > Shutting down eww daemon...
 2022-05-02T13:26:06.196Z INFO  eww::app                > Received kill command, stopping server!
 2022-05-02T13:26:06.196Z INFO  eww::server             > main application thread finished

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.

[Saul-Dickson]

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.

[Swexti]

What command are you using to run eww?

Just the normal eww open <window name>, I'm not using any config location flag, no.

[madser123]

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

[fuku77]

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).

[tkapias]

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

[carlfarrington]

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.

[carlfarrington]

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,

[carlfarrington]

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")

[elkowar]

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

[Lannselot]

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.

[solarsalix]

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)

[carlfarrington]

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.

[amplexus]

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

[DreamMaoMao]

same problem ,Is there any progress on this issue?

[sergio222-dev]

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)

[DreamMaoMao]

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.

[interbattles]

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)