EWW Filling ~/.chache With Massive 500G Log [BUG]

[ghost]

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

A massive log file is generated in ~/.cache.

Here is the (eww-related) output of ls -la in ~/.cache:

.rw-r--r-- 52k isaac 20 Apr 15:45  eww_9056c77df6de77d0.log .rw-r--r-- 267M isaac 20 Apr 09:14  eww_a10aa33e2445ee6b.log .rw-r--r-- 531G isaac 20 Apr 16:00  eww_b8f4ff56cd76310e.log .rw-r--r-- 83M isaac 20 Apr 15:43  eww_bf24495fb8cff968.log .rw-r--r-- 22k isaac 20 Apr 15:46  eww_cb86edef4769841d.log .rw-r--r-- 836k isaac 20 Apr 15:37  eww_f50d6af04696deab.log .rw-r--r-- 2.1M isaac 20 Apr 06:02  eww_fa678f477ccfc02e.log

I deleted the file and purged my trash yesterday and checked to ensure the space was free, but after a day it's already back.

Reproducing the issue

My configuration is visible here: https://gitlab.com/IsaacBrown92/dotfiles/-/tree/main/home-manager/modules/eww

Other than that I have no idea how to reproduce the issue. I cannot tell why the behaviour is happening.

Expected behaviour

No response

Additional context

No response

[elkowar]

Lmao, okay I knew I should really put logs somewhere else, or do some sort of log rotation, but a 500 gig file is a very good reason to start implementing that now. Thanks, I hope your hard drive is doing well ^^'

[ghost]

Hahaha, epic thanks. Yeah it pwned my hardrive once already. :P

[NoXPhasma]

As a workaround you could set a custom path for logging, I use /tmp which is tmpfs: env XDG_CACHE_HOME=/tmp eww open ...

[grm34]

Issue of the year, I got a 92.7G one on a 128G SSD I'm ready to rumble 🤣

[viandoxdev]

Any specific line the log file is filled with ? Because that would help debugging this

[grm34]

@viandoxdev no sorry, I didn't bother to open it, system was overheading.

I will now pay attention to it.

From memory, it seems to be because of a zellij session left open on the logs. SSD at 16% when I go to bed and 99.9% when I wake up.

Another thing that could maybe help, hot reloading sometimes doesn't work. I use pkill in that case to stop the daemon, maybe a bad killed process.

[ecribia]

Im having the same issue as mentioned above. Im using someone elses eww bar, so i dont really know how to configure it to save the log in /tmp... Would be very appreciated if someone could tell me.

[grm34]

@Azkaas like @NoXPhasma said, open your widgets with :

env XDG_CACHE_HOME=/tmp eww open my_awesome_widget

You can also add the variable to your environment, example for bash edit ~/.bashrc :

export XDG_CACHE_HOME="/tmp"

[viandoxdev]

@Azkaas like @NoXPhasma said, open your widgets with :

env XDG_CACHE_HOME=/tmp eww open my_awesome_widget

You can also add the variable to your environment, example for bash edit ~/.bashrc :

export XDG_CACHE_HOME="/tmp"

Note that you probably shouldn't export XDG_CACHE_HOME to /tmp as it could pretty much break caching on your computer, better to use the first solution (just for eww)

[ecribia]

Thanks for the response guys :) I actually ended up using rm -rf command on the log on each login for now. But I imagine writing over and over isnt healthy for the SSD

[ecribia]

Just to give a minor update if someone is looking to solve the bug, this is what my log gets filled with:

[ModestTom]

I am also having this spammed in my log file. I had a 112G log file. I was making changes to one of the window files I have and I couldn't even write my changes cause I ran out of space lol.

Caused by:
    Couldn't upgrade reference, widget got deallocated
   2023-05-25T13:03:47.656Z ERROR eww::error_handling_ctx > Error while updating UI after state change

[viandoxdev]

Well if you can patch eww, getting rid of the log is an easy workaround for this bug. The real solution would be to fix the underlying bug with widget deallocation tho.

[ModestTom]

@viandoxdev I do already patch eww for kb support so I would love to do that if you could point me in the right direction to disable the logging.

[viandoxdev]

@viandoxdev I do already patch eww for kb support so I would love to do that if you could point me in the right direction to disable the logging.

Here, looking at it now, its not as trivial as removing the log (though you could look at where the returned error is logged and remove that instead) if you can either do what the comment says (that might be the fix) or try to return from the closure there and avoid processing further.

[ModestTom]

So I got the spam to stop by the former option (removing the call for error log reporting this error). How I went about this was by commenting out lines 212, 226, and 296 from crates/eww/src/state/scope_graph.rs. I saw the note about the listener but it's a little more than I've got time for unfortunately. Note, this is not a proper solution but it allows for you to be rid of large log files and still receive errors for things you want. @viandoxdev thanks for the tip. After 10 minutes I would usually have 10G consumed by that log file lol.

[burntchipset]

i was too lazy to fix the issue and i noticed the log file had the same name every time so i just added rm command with the path of the log to startup.

[ariealerr]

This is an issue that's really putting me off from using EWW as a daily-driver. The log files just get so big. And as someone who uses a lot of literal scripts, the logs fill up quickly. I keep my system running for days on-end, so keeping everything inside /tmp still creates huge log files. I wonder if it would be possible to routinely remove the log file as a workaround?

Would really like Elk to get working on this.

EDIT: on further inspection, my literal scripts do not fill up my log files, actually. They still get really big, though. But not because of my scripts.

[viandoxdev]

@Swexti You could try #821 as a workaround, should limit the total number of "Widget got deallocated" logs to 10 per daemon. I haven't tested it yet tho as my config doesn't generate these logs

[ariealerr]

@Swexti You could try #821 as a workaround, should limit the total number of "Widget got deallocated" logs to 10 per daemon. I haven't tested it yet tho as my config doesn't generate these logs

Will take a look, thanks!

[hakan-demirli]

@Swexti Just pipe that log file to /dev/null.

ln -sf /dev/null ~/.cache/eww_*.log

Inspired from webscale mango db.

[ColdMacaroni]

For those that want to stay on the main branch, I've set up a cronjob to delete lines like these from the logs:

Caused by:
    Couldn't upgrade reference, widget got deallocated
   2023-05-25T13:03:47.656Z ERROR eww::error_handling_ctx > Error while updating UI after state change

It helps to keep log size down while not losing any other info from there. Here it is (set to run every 20 minutes, requires perl and sed):

*/20 * * * * perl -0777 -i -pe 's/\nCaused by:\n    Couldn'"'"'t upgrade reference, widget got deallocated\n.*/<DELETEME>/g' $HOME/.cache/eww*.log && sed -i '/^<DELETEME>$/d' $HOME/.cache/eww*.log

('"'"' is to place a ' without escaping. I couldn't get perl to delete the lines so i'm using a placeholder string)

[Horryportier]

So as i can see this is not fixed yet eww verison : eww 0.4.0 a9a35c1804d72ef92e04ee71555bd9e5a08fa17e I was rally panicking that my pc just broke (couldn't safe anything etc. )