Eopkg error - Freeze - Crash!

qk4-li3

I've got a pattern here: eopkg error - freeze -crash.
I've just found out how I can reproduce it:

Open Solseek and choose search all packages.
Start scrolling the package list until message appears: "Error, couldn't unpack the fle to target path, no space left on device"
Then whole operating system (Budgie DE) becomes unresponsive and finally crashes. Crash breaks Bottom Panel, which I now know how to restore.
Free space during testing was 10,3 GB. Now after reboot it shows 10,1 GB.

So, what's that all about?

Bhibb

qk4-li3 Could be that the 'free space' is in the wrong place for your packages. Do you have a special location for your /var, /home, and others?

qk4-li3

Bhibb Must be something like that. But I haven't personally (at least knowingly) changed any paths. I wouldn't know how to do that.
Could there be some setting for example in Discoverythat could be accidentally clicked with mouse, or something along those lines? Like, for instance, in some software you can accidentally change "combo-box" values, when you're intention is only scroll down the page. I hate when that happens.
When I have tried to use DiscoveryI find it oftentimes tells me "something went wrong try again later" and then eopkg or solseek would just work instead, until now.
How would I verify that right paths are in place?
edit. well I think my home folder is in normal place /home/my_home/
edit2 typo

pomon

Post the output of these commands:

df -h
du -sh /var/cache/eopkg
df -h /tmp

Then open two terminal windows. In the first one run:

watch -n 1 du -sh /var/cache/eopkg

In the second one reproduce the problem (open Solseek, search all packages, start scrolling) and watch if the cache size grows in real time.

If it crashes and requires a hard reset, after reboot post the output of:

journalctl -b -1 -p err

qk4-li3

pomon watch -n 1 du -sh /var/cache/eopkg

Using that command, I only saw static 28M /var/cache/eopkg on the left side and my username and clock ticking away on right upper corner of terminal window. So this 28M figure didn't grow or go anywhere, just stayed same (while scrolling package list).

qk4-li3

hmm, that suspicious new packagekit stuff though... 🤔

qk4-li3

df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 49G 37G 9,5G 80% / devtmpfs 1,4G 0 1,4G 0% /dev tmpfs 1,5G 27M 1,4G 2% /dev/shm tmpfs 581M 1,8M 579M 1% /run tmpfs 1,0M 0 1,0M 0% /run/credentials/systemd-journald.service tmpfs 1,0M 0 1,0M 0% /run/credentials/systemd-resolved.service tmpfs 1,5G 6,1M 1,5G 1% /tmp tmpfs 291M 200K 290M 1% /run/user/1000

qk4-li3

du -sh /var/cache/eopkg 28M /var/cache/eopkg

qk4-li3

df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs 1,5G 6,1M 1,5G 1% /tmp

pomon

Scrolling through packages in Solseek fills up /tmp (tmpfs). You can see it on my screenshot — scrolled only to "l" packages and already at 1.6G. With only 1.5G /tmp (3GB RAM) this will cause a system freeze. The files remain in /tmpeven after closing Solseek. Can anyone confirm this?

qk4-li3

I think I can confirm.
I've been busy crashing my machine and then I saw your post and guessed from the screenshot the "spell" you used. So I had to try. The moment tmpfs is full, the error occurs and freezing starts.
Had to take picture with my camera because screenshot wouldn't work, I guess because tmpfs was full(?).
And yes, tmpfs remains full. Even after successful log out and successful re-login, tmpfs was full, so it didn't take much time system to crash again, this time no recovery.

qk4-li3

Ok, did you miss my post @pomon ?

pomon watch -n 1 du -sh /var/cache/eopkg was my mistake — I thought the metadata was written there.

Ok.

pomon You should check watch -n 1 df -h /tmp instead.

That's exactly how my "non-educated guess" was. I guessed it from your screenshot.

pomon By confirmation I mean checking whether the data in /tmp is still there after closing Solseek.

qk4-li3 And yes, tmpfs remains full.

After closing solseek, yes. And...

qk4-li3 Even after successful log out and successful re-login, tmpfs was full, so it didn't take much time system to crash again, this time no recovery.

Axios

With that command I scrolled I looked (df -h /tmp)
But this as high as I could get it to go
I just did an update to Kde to 50 files

Note:But I have 24gig ram tho

Shrugs Hope this helps

This command tho (u -sh /var/cache/eopkg) 6.7G
My disk space is at 63%

qk4-li3

Axios watch -n 1 df -h /tmp

that was the correct one to use while scrolling, or did you figure that out already, if not go ahead and try that.

Harvey

As it seems like a potential solseek issue, pinging @Clintre

pomon

watch -n 1 du -sh /var/cache/eopkg was my mistake — I thought the metadata was written there. You should check watch -n 1 df -h /tmp instead.

By confirmation I mean checking whether the data in /tmp is still there after closing Solseek. It seems only a reboot clears it.

Axios

qk4-li3 Ya after scrolling around got it to around 2gig
but after reboot it cleared and was back to normal.

No I went out mowing..lol thanks for letting me know

Harvey

tmpfs (/tmp) is just files stored in RAM, the system will not recognise tmp as something that can be safely dropped to swap or cleared especially if it was recently used, it thinks its required.

solseek is a bash script so it cannot do proper memory allocation / management. I assume its using tmpfs to avoid doing costly (time) tasks repeatedly when it can just re-use the data from its first usage leading to the app feeling more responsive.

Data put in tmp will not automatically get cleared when the process that created it is closed, the app needs to clean up after itself.

So no a re-log will not clear it but a reboot will purely because RAM is volatile and a reboot will momentarily cut power to the RAM flushing its contents.

Axios

Harvey I just crashed budgie by filling up tmpfs to 100% I am using plank so a reboot was all that was needed.
Good to know this
Correct my if wrong doesnt tmpfs get swapped out?
My budgie is just 4g as my kde is 24g so i can see how it can happen quickly on low memory systems.

Harvey

I don't think its reliable. It may be moved to swap if it goes a long time without being used by anything and the system needs the space but thats just trusting the system to figure it out. Any time I write something that uses tmpfs I make sure it gets cleared so I don't have any experience in how it'd work in practice.