After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 649398 - [gnome-system-monitor]3.0.0-1 takes ~10 sec to quit
[gnome-system-monitor]3.0.0-1 takes ~10 sec to quit
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: general
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
: 672951 673503 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-04 17:46 UTC by siriusb
Modified: 2013-08-01 03:02 UTC
See Also:
GNOME target: ---
GNOME version: 2.91/3.0


Attachments
strace output (862.63 KB, text/plain)
2011-05-04 17:46 UTC, siriusb
  Details
Proposed patch (4.83 KB, patch)
2011-11-06 05:15 UTC, Robert Roth
none Details | Review
Use a tuple to store window state (3.47 KB, patch)
2013-07-31 10:10 UTC, Stefano Facchini
committed Details | Review
Save sort column and order when they change (3.15 KB, patch)
2013-07-31 10:11 UTC, Stefano Facchini
committed Details | Review

Description siriusb 2011-05-04 17:46:45 UTC
Created attachment 187221 [details]
strace output

System monitor hangs for 8-10 sec after closing window then a Force Quit window flashes for a moment and system monitor finally quits.
Comment 1 siriusb 2011-05-04 17:49:38 UTC
Gnome 3.0.1
gnome-system-monitor 3.0.0-1
kernel26 2.6.38.5-1
nvidia 270.41.06-1
Comment 2 Chris Kühl 2011-05-12 23:00:05 UTC
While my machine doesn't take nearly as long as your to close g-s-m, there is definitely a noticeable lag. I'll look into it.

Thanks for the bug report.
Comment 3 Jean-François Fortin Tam 2011-05-31 03:50:35 UTC
I have noticed that g-s-m scrapes the hard drive a lot while this happens. What is it trying to write to?
Comment 4 Jean-François Fortin Tam 2011-10-16 02:17:26 UTC
Hey there Chris, I'm still seeing this in 3.2. Looking at the strace above it does look like it's trying to read a ton of files when exiting, why is that?
Comment 5 Chris Kühl 2011-10-17 07:49:22 UTC
Not sure yet. I've not had much time to look at system-monitor lately. I'll try to get to it ASAP. If anyone submits a patch that fixes this I'd quickly review it.
Comment 6 Robert Roth 2011-11-06 03:31:33 UTC
This seems to be caused by the g_settings usage of the procman_save_tree_state method, when it does save the column settings. Maybe that info should also be saved right when changing (as it happens with the spinbuttons) so it will not be required to iterate through each column and save all information for them.
Comment 7 Robert Roth 2011-11-06 05:15:10 UTC
Created attachment 200808 [details] [review]
Proposed patch

Attached a patch moving the column preferences g_settings saving out of the update called on the end. The proposed patch saves the column width after resize for the column resized (have to do this only for one column, the updated one, no iteration needed) and saves the column visibility settings when changed from the preferences (only for the toggled column, no iteration needed here either). This reduces the quit time a bit, and there is no huge HDD activity peak anymore (there still is a smaller one, as some g_settings keys still have to be saved on quit).
Comment 8 Chris Kühl 2011-11-08 08:47:25 UTC
This problem has been fixed with commit bc2a8c221604fe335b690ba7d180022bf0430fff in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 9 Chris Kühl 2012-03-29 11:41:59 UTC
*** Bug 672951 has been marked as a duplicate of this bug. ***
Comment 10 André Klapper 2012-04-05 09:44:41 UTC
*** Bug 673503 has been marked as a duplicate of this bug. ***
Comment 11 David Gomes 2012-04-23 21:09:43 UTC
I now have Gnome 3.4, and I still get a little lag, like 1.5 seconds to close.
Comment 12 Alex Hultman 2012-04-24 05:31:17 UTC
+1. I'm not really satisfied with this fix. My hdd shouldn't be involved in checking cpu load or closing a process.
Comment 13 Chris Kühl 2012-04-24 06:46:22 UTC
(In reply to comment #12)
> +1. I'm not really satisfied with this fix. My hdd shouldn't be involved in
> checking cpu load or closing a process.

Actually it's very much involved in saving settings on close.

Could someone please provide an strace as the first post did.
Comment 14 Chris Kühl 2012-07-29 14:07:35 UTC
I'd be interested in looking at an strace from David or Alex.
Comment 15 David Gomes 2012-07-29 14:23:09 UTC
Here it is, I just open gnome-system-monitor and right after send a close signal by my Window Manager.

I tried to attach the text file, but it's too big.

https://raw.github.com/gist/84884a98f8c79da60b07/d6f02b907ee2c5d009f646566847de462e78cc92/gnome_system_monitor_trace.txt
Comment 16 Stefano Facchini 2013-07-31 10:10:56 UTC
Created attachment 250529 [details] [review]
Use a tuple to store window state

It's faster to set a single gsettings tuple than four integers.

Also, remove g_settings_sync() as it's automatic
Comment 17 Stefano Facchini 2013-07-31 10:11:15 UTC
Created attachment 250530 [details] [review]
Save sort column and order when they change

Instead of doing that at shutdown and delaying exit
Comment 18 Robert Roth 2013-08-01 02:26:53 UTC
Attachment 250529 [details] pushed as d347dd1 - Use a tuple to store window state
Attachment 250530 [details] pushed as 5b836af - Save sort column and order when they change
Comment 19 Robert Roth 2013-08-01 03:02:12 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.