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
Created attachment 293583 [details] Attached /var/log/messages with error message, as well as a echo t>/proc/sysrq-trigger while process was hung
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
Created attachment 293584 [details] sysreport
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
Created attachment 293585 [details] gconfd core file
Created attachment 293590 [details] gconftool-2 script
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 "?".
It's highly likely anything will be done for this bug.
I agree, at this point in the RHEL4 cycle it may be too late to address this type of bug.