Bug 431056

Summary: gconf dies after several gconftool-2 -s calls
Product: Red Hat Enterprise Linux 4 Reporter: Alan Matsuoka <alanm>
Component: GConf2Assignee: Ray Strode [halfline] <rstrode>
Status: CLOSED WONTFIX QA Contact: desktop-bugs <desktop-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.6CC: tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-18 18:15:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Attached /var/log/messages with error message, as well as a echo t>/proc/sysrq-trigger while process was hung
none
sysreport
none
gconfd core file
none
gconftool-2 script none

Description Alan Matsuoka 2008-01-31 14:49:34 UTC 
escription of problem:
In order to setup a locked-down environment, customer used a ".gconf/" tarball
that was expanded on user's home-dir.

As this is not very clear, as it just replaces everything without having any
comment on what's doing, my idea was to drop a standard user, and then, using
gconftool-2 edit each of the customizations that we do for users, in order to
remove panels, change settings, etc.

So I wrote a script with about 183 gconftool sentences in order to change this
settings.

The problem appears when sometimes it works, and sometimes it complains (like if
gconf were dead), so I need to CTRL-C on script, then kill gconfd and reaply
script...

Thera are some messages on /var/log/messages saying that the entry couldn't be
written (the message was in spanish, but the translation should be like
that).... This doesn't happens always, but once happened, I need to manually
kill gconf in order to continue setting values


How reproducible:
Execute many gconftool -s  sentences for setting config values

Steps to Reproduce:
- Create a new gnome user
- Modify lots of settings using gconftool-2
- See output at /var/log/messages


Actual results:

Sometimes it fails, needeeing to kill gconf in order to restart processs

Expected results:

Something that works (TM) ;)

Additional info:
- Attached is the slimmed down version of the script (removed some panel removal
instructions)

- This happened both with GNOME environemnt loaded and with just console access,
appliying config to USER
Comment 1 Alan Matsuoka 2008-01-31 14:49:34 UTC 
Created attachment 293583 [details]
Attached /var/log/messages with error message, as well as a echo t>/proc/sysrq-trigger while process was hung
Comment 2 Alan Matsuoka 2008-01-31 14:50:16 UTC 
The problem doesn't reproduce every time but 1 out of 5 approx.

In the steps to reproduce the "Modify lots of settings using gconftool-2" is
basically execute the perfil_gnome.shdl script which does exactly this.

Thanks,

Ramon
Comment 3 Alan Matsuoka 2008-01-31 14:51:14 UTC 
Created attachment 293584 [details]
sysreport
Comment 4 Alan Matsuoka 2008-01-31 14:56:07 UTC 
 You can make it happen more frequently if you delete .gconf and
.gconfd and retry.

Sometimes it works fine, sometimes it fails :)
-----------------
Event posted 11-15-2007 04:41pm EST by alanm 

The messages mean "Failed to write ... Failed to open ... file or directory does
not exist"

It's generated near

#: backends/markup-tree.c:3720 backends/markup-tree.c:3734
#, c-format
msgid "Failed to open \"%s\": %s\n"
msgstr "Fall� al abrir �%s�: %s\n"


When gconftool-2 hangs, I could use a stack trace.

look for the pid of the  hanging gconftool-2 .i.e. 12345 and do a
pstack 12345

and let's see where it's hanging.
do the same for
/usr/libexec/gconfd-2
and see what's happening there as well.
---------------------
Alanm,

> When gconftool-2 hangs, I could use a stack trace.

gconftool-2 doesn't hangs, just gconfd that seems to stop accepting more
requests from gconftool, throwing loads of error mesages at /var/log/messages

Will run psstack on gconfd and attach messages here :)

Thanks! 
-----------------------
rpm -qa|grep debug
GConf2-debuginfo-2.8.1-1.el4


(gdb) bt
#0  0x00c207a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0033d081 in send () from /lib/tls/libc.so.6
#2  0x00338446 in vsyslog () from /lib/tls/libc.so.6
#3  0x0033868f in syslog () from /lib/tls/libc.so.6
#4  0x00bcd48a in gconf_log (pri=GCL_WARNING, fmt=0xb7dc5f68 "Ha ocurrido un
error al escribir \"%s\": %s\n")
   at gconf-internals.c:1153
#5  0x0019c563 in markup_dir_sync (dir=0x829f108) at markup-tree.c:1019
#6  0x0019c262 in markup_dir_sync (dir=0x829a710) at markup-tree.c:1059
#7  0x0019c262 in markup_dir_sync (dir=0x8297830) at markup-tree.c:1059
#8  0x0019c262 in markup_dir_sync (dir=0x8293a80) at markup-tree.c:1059
#9  0x0019c62e in markup_tree_sync (tree=0x82939b0, err=0xfffffe00) at
markup-tree.c:359
#10 0x00196a0c in sync_all (source=0xfffffe00, err=0xfffffe00) at
markup-backend.c:771
#11 0x00bd8b8d in gconf_sources_sync_all (sources=0x8293c20, err=0xbfee6e74) at
gconf-sources.c:288
#12 0x0804d98c in ?? ()
#13 0x08293c20 in ?? ()
#14 0xbfee6e74 in ?? ()
#15 0xbfee6e78 in ?? ()
#16 0x001558f9 in g_thread_self () from /usr/lib/libglib-2.0.so.0
#17 0x0804da51 in ?? ()
#18 0x00155c1c in g_static_private_get () from /usr/lib/libglib-2.0.so.0
#19 0x0013ea98 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0
#20 0x0013b74b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0x0013d1d2 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#22 0x0013d47f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#23 0x08050f91 in ?? ()
#24 0x08294078 in ?? ()
#25 0x08294078 in ?? ()
#26 0x00000000 in ?? ()
(gdb) stack
Undefined command: "stack".  Try "help".
(gdb) cont
Comment 5 Alan Matsuoka 2008-01-31 14:57:04 UTC 
Created attachment 293585 [details]
gconfd core file
Comment 6 Alan Matsuoka 2008-01-31 15:29:52 UTC 
Created attachment 293590 [details]
gconftool-2 script
Comment 7 RHEL Program Management 2008-10-31 16:47:51 UTC 
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 8 Alan Matsuoka 2009-02-18 15:26:26 UTC 
It's highly likely anything will be done for this bug.
Comment 9 Ray Strode [halfline] 2009-02-18 18:15:25 UTC 
I agree, at this point in the RHEL4 cycle it may be too late to address this type of bug.