Repository navigation
Vitals freezes gnome-shell after sleep (?) #582
Description
Has this issue been covered in the Wiki?
- I have read the Wiki and my issue is not covered.
Is there an existing issue reported already?
- I have searched the existing issues, it does not exist.
What is the unexpected behavior?
Every time I unlock my computer, after a long while (laptop has moved to sleep), gnome-shell unlocks, but it is unresponsive for ~3 minutes.
Network applets have "..." as value.
After browsing https://extensions.gnome.org/extension/3010/system-monitor-next/, I saw mgalgs/gnome-shell-system-monitor-next-applet#153.
Could it be that this extension is also vulnerable to this bug?
Searched for:
- https://github.com/corecoding/Vitals/issues?q=sort%3Aupdated-desc%20freezing
- https://github.com/corecoding/Vitals/issues?q=sort%3Aupdated-desc%20freeze
Steps to reproduce the unexpected behavior.
Every time I unlock my computer, after a long while (laptop has moved to sleep), gnome-shell unlocks, but it is unresponsive for ~3 minutes.
Network applets have "..." as value.
Relevant log output
What distribution and version of Linux are you using?
Ubuntu 22.04
What version of Gnome are you using?
42
Activity
stdedos commentedon Aug 19, 2026
And I am relatively sure you might be affected - because now that Vitals is disabled, unlocking my user does not end up in me waiting 3 minutes almost totally frozen
corecoding commentedon Aug 20, 2026
This is the first time I've heard of this issue. The current Gnome versions that are supported are v45 through v50. I am unable to post updates to version 42. I believe you are talking about two separate issues. Please see https://github.com/corecoding/Vitals/wiki/Sensor-shows-%22...%22-in-menu-bar and https://github.com/corecoding/Vitals/wiki/System-periodically-freezes - in other words, try disabling all sensor groups and enable just one at at time.
I would recommend upgrading to ubuntu 23.10 which gnome 45 which will give you a much newer version of Vitals.
stdedos commentedon Aug 20, 2026
I should've mentioned I've seen this. This has to do with the wifi adapter, so ... the "sensor" (wlan0) did not "disappear". It is just not connected.
gnome-shell almost completely freezes (even the clock) - so I am unable to disable all sensor groups live. Doing them once per replication (every couple of hours) would take a lot. (or maybe I would be lucky and the wlan0 would indeed be the problematic sensor group).
This is also a very old system (Intel i7-4600U), so it could be that as well.
I am in the process of slowly updating to tl;dr latest Ubuntu (and I will try at 26.04). I am just giving you a heads up - as mgalgs/gnome-shell-system-monitor-next-applet#153 seems like a pesky bug to discover 🙏
corecoding commentedon Aug 20, 2026
I appreciate the report. You mentioned WiFi, but the PR talks about network storage. Is your file system by chance on a network, not on real media? AI did tell me that fsusage, an API in Gnome, can cause delays if you poll a location that disappears / stops existing. I wonder if your WiFi is dropping out and causing the file system to become unresponsive? That's the only thing I can deduce.
stdedos commentedon Aug 20, 2026
I noticed that - you are right that they are a bit disjoint.
I saw only wlan0 tracking being
"..."(and read https://github.com/corecoding/Vitals/wiki/Sensor-shows-%22...%22-in-menu-bar), and I also noted that "for some reason" gnome-shell extensions are "working on the gui thread".On old tech, could it be that wifi is "slow" to come up - and if this extension too "can block" while polling wlan0 stats - could it be a similar problem?
I genuinely don't know, as I haven't read the extension's code 🙏
/var/log/syslogandjournalctl --since=5.min.ago --followshows nothing. (or rather - it shows things likewhich are (probably) not related to Vitals)
I don't know how to debug further 🙏
It could be - as wifi "drops out" when the computer sleeps.