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 652289 - GDM Endlessly Writes to Saved_State Causing Failure
GDM Endlessly Writes to Saved_State Causing Failure
Status: RESOLVED FIXED
Product: GConf
Classification: Deprecated
Component: gconf
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GConf Maintainers
GConf Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-06-10 13:41 UTC by David Richards
Modified: 2012-02-21 22:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the saved_state file sitting in the .gconfd folder of $HOME for gdm (33.82 KB, application/x-bzip)
2011-06-10 13:41 UTC, David Richards
  Details
daemon: store saved_state in daemon dir not ~/.gconfd (989 bytes, patch)
2011-06-10 23:07 UTC, Ray Strode [halfline]
committed Details | Review
daemon: store daemon data in XDG_RUNTIME_DIR (1.31 KB, patch)
2011-06-10 23:07 UTC, Ray Strode [halfline]
committed Details | Review
daemon: tie saved_state file to session (4.35 KB, patch)
2011-06-10 23:08 UTC, Ray Strode [halfline]
committed Details | Review

Description David Richards 2011-06-10 13:41:41 UTC
Created attachment 189630 [details]
the saved_state file sitting in the .gconfd folder of $HOME for gdm

A certain unknown event is triggering gdm to write to saved_state over and over again.  As new users attempt to authenticate their temporary gdm gconfd session is attemping to read in this file and leak horribly.  Each new users gets a bigger and bigger memory footprint.  Eventually the server becomes unusable.

Attaching the last 4000 lines of the saved_state file.

Ours had grown to almost 6GB before the server was rebooted.

Once I moved the file out of the way and killed the errant gdm's, the problem went away.
Comment 1 Ray Strode [halfline] 2011-06-10 13:44:18 UTC
saved_state is gconf actually, moving
Comment 2 Ray Strode [halfline] 2011-06-10 23:06:26 UTC
so i can't claim to know exactly why the saved_state file is growing to 6GB, but I do know from reading through the code that the saved_state file is not really designed to be written to by multiple gconfd's at the same time.  Each one will stomp on the others toes, causing unexpected weirdness.  It could very well be that the "stomping" makes stale entries stick around causing the file to grow without bound (although from quickly looking I can't quite see how)

I'll attach some patches to make saved_state per-session instead of per-user like the rest of gconfd is.
Comment 3 Ray Strode [halfline] 2011-06-10 23:07:49 UTC
Created attachment 189700 [details] [review]
daemon: store saved_state in daemon dir not ~/.gconfd

The daemon dir isn't always ~/.gconfd so we shouldn't hard
code it.
Comment 4 Ray Strode [halfline] 2011-06-10 23:07:58 UTC
Created attachment 189701 [details] [review]
daemon: store daemon data in XDG_RUNTIME_DIR

If XDG_RUNTIME_DIR is available it's a much better
directory than /tmp since it ensures there's no
DoS possibilities
Comment 5 Ray Strode [halfline] 2011-06-10 23:08:01 UTC
Created attachment 189702 [details] [review]
daemon: tie saved_state file to session

The code isn't really designed to work well with multiple
gconfd's writing to the same saved_state file, so we should
make it per-session.
Comment 6 Ray Strode [halfline] 2011-08-29 18:53:08 UTC
Did these patches work for you okay, Dave?
Comment 7 Bjørn Lie 2011-09-18 11:54:12 UTC
Ray - this is the downstream bug, no final conclution is reached there either.
Comment 8 Bjørn Lie 2011-09-18 11:55:05 UTC
Err - what if I included the link - sorry

https://bugzilla.novell.com/show_bug.cgi?id=699849
Comment 9 Ray Strode [halfline] 2011-10-26 18:19:42 UTC
I would still appreciate feedback on these patches if you've had a chance to try them.
Comment 10 Tobias Mueller 2012-02-07 00:22:19 UTC
Reopening as I can't see any open non-developer question.
Comment 11 Ray Strode [halfline] 2012-02-21 22:39:05 UTC
I talked to Dave about these today. He said they've been working okay (though he has som cronscripts to clean things up that might not making testing 100% pristine.

I'll probably push these soon.
Comment 12 Ray Strode [halfline] 2012-02-21 22:52:02 UTC
It's less important now that we don't use ORBit by default, but pushed
anyway to get it off my radar.

Attachment 189700 [details] pushed as ea68943 - daemon: store saved_state in daemon dir not ~/.gconfd
Attachment 189701 [details] pushed as 2895a09 - daemon: store daemon data in XDG_RUNTIME_DIR
Attachment 189702 [details] pushed as 14176e6 - daemon: tie saved_state file to session