35
My KDE Neon becomes unresponsive almost daily
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 29 Jan 2026
35 points (100.0% liked)
Linux
57274 readers
372 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 6 years ago
MODERATORS
It may not be the raw RAM usage.
My first suspect is the Windows VM especially if it's running enterprise security software 4GB is probably not enough for modem Windows and it could be trying to use its page file, thrashing your disk in the process.
Are you able to collect some data from system monitor on paging and disk activity? That could help you narrow it down. You can use btop for a quick terminal option if your gui is non responsive (assuming your could switch to a console). Vmstat is another option that you can run in the background to collect stats over time, but it's not user friendly.
Nothing much enterprise...It's running "Windows App", just a glorified RDP with extra authentication settings for SSO etc. Hence why I gave it only 4GB. It's not just GUI not being responsive, everything is. It's a full freeze, and I can't get to the text consoles either. Most I can aspire to, I think, is to gather data from right before the freeze happens....and check it after I reset the computer.
I see. My concern was with security scanning tools often put on computers by enterprise IT departments but it sounds like that's not the case here.
In your situation, assuming you're not finding what you seek with journalctl, I think I would use a tool like vmstat or
sarto collect periodic snapshots of CPU, memory, and io. You can tell it to collect data every X seconds and tee that to a file. After you reboot you can see what happened leading up to the crash. You should be able to import the data into a spreadsheet or something for analysis, but it's not very intuitive and you'll need to consult man pages for the options and how to interpret them.There are a lot of good suggestions in this thread. I would lean towards a hardware or driver issue, maybe bad RAM. Unfortunately these things take a lot of trial and error to figure out.