gconfd-2 doesn't stop for previous user logged into GNOME

Thanks for your bug report. Could you try to open a backtrace (https://wiki.ubuntu.com/Backtrace) for the gconfd-2 process when it's using cpu. Could you also try to "strace -p PID" it and not what it's doing to a comment

I'm glad that I still haven't rebooted since then to get rid of the annoying situation and the observed anomaly still eats almost all of my CPU cycles, so here is the requested info.

First of all, I am unable to do successfully "(gdb) attach <PID>" as described in the wiki -- I get "no permission". Is it safe to run the gdb commands from the wiki as root?

"sudo strace -p 5771" was more straightforward and resulted in a continuously scrolling (> 3000 lines until a CTRL+C) message:

--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
Process 5771 detached

HTH!

Well, I have tried to run the described steps (for an already running program) with sudo and here the output is attached.

It is interesting that after issuing "attach 5771" the CPU usage dropped to normal levels (2-3%), but when I said "quit" at the gdb prompt and "exited anyway", the CPU was again at 100% use by the same process.

Thank you for the work on that. That's normal that the CPU usage stops when gdb attach the process because it stops it. The backtrace looks like a problem, it lacks details to be useful though. Could you try to build a debug package for gconf2 as explained on https://wiki.ubuntu.com/DebuggingProgramCrash?

I'm affraid that I'm not proficient with building debs, but I'll try to do my best to resolve this issue.

If I face the described situation again, should I post here the same type of info as I already did? Or is there something else to have in mind while using the debug package?

Building the debug packages turned out to be much easier than I thought, but after installing them the update-manager wants to update these -- I suppose that I don't want to do that unless I've finished using the debug version.

Waiting for the bug to come again;)

Thanks for the help sofar, Sebastien!

Since my bugreport I hadn't experienced the unusually high CPU usage for gconfd-2, but I noticed that the respective process for previously logged user(s) still persists. I don't know if this behaviour is normal or not, but I assume that the high CPU usage comes when the "relict" process has experienced segmentation fault.

For the record here I provide the output of the previously undertaken diagnostics, this time with an apparently intact gconfd-2 process:

$ pidof gconfd-2
6328 6392

[6328 is the remaining process]

$ sudo strace -p 6328
Process 6328 attached - interrupt to quit
futex(0xb7e06320, FUTEX_WAIT, 2, NULL
 <unfinished ...>
Process 6328 detached

$ sudo gdb 2>&1 | tee gdb-gconfd-remaining-process.txt
Password:
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(gdb) handle SIG33 pass nostop noprint
Signal Stop Print Pass to program Description
SIG33 No No Yes Real-time event 33
(gdb) set pagination 0
(gdb) attach 6328
Attaching to process 6328
Reading symbols from /usr/lib/libgconf2-4/gconfd-2...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Reading symbols from /usr/lib/libORBit-2.so.0...done.
Loaded symbols for /usr/lib/libORBit-2.so.0
Reading symbols from /usr/lib/libglib-2.0.so.0...done.
Loaded symbols for /usr/lib/libglib-2.0.so.0
Reading symbols from /usr/lib/libgconf-2.so.4...done.
Loaded symbols for /usr/lib/libgconf-2.so.4
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread -1211713856 (LWP 6328)]
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /usr/lib/libgmodule-2.0.so.0...done.
Loaded symbols for /usr/lib/libgmodule-2.0.so.0
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/libpopt.so.0...done.
Loaded symbols for /lib/libpopt.so.0
Reading symbols from /usr/lib/libgobject-2.0.so.0...done.
Loaded symbols for /usr/lib/libgobject-2.0.so.0
Reading symbols from /usr/lib/libgthread-2.0.so.0...done.
Loaded symbols for /usr/lib/libgthread-2.0.so.0
Reading symbols from /lib/tls/i686/cmov/libm.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_compat.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_compat.so.2
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /lib/tls/i686/cmov/libnss_nis.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_nis.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_files.so.2...don...

Thank you for your work on that. Marking unconfirmed. What is that " relict" program doing?

The problem appeared again, so here are the (hopefully helpful) backtrace (attached) and the output of strace:

~$ strace -p 7238
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
ivailo@darkstar:~$ sudo strace -p 7238
Process 7238 attached - interrupt to quit
gettimeofday({1172324704, 520340}, NULL) = 0
gettimeofday({1172324704, 520494}, NULL) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}], 6, 4917) = 0
gettimeofday({1172324709, 443822}, NULL) = 0
time(NULL) = 1172324709
time(NULL) = 1172324709
gettimeofday({1172324709, 444222}, NULL) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}], 6, 30000) = 0
gettimeofday({1172324739, 449479}, NULL) = 0
time(NULL) = 1172324739
time(NULL) = 1172324739
gettimeofday({1172324739, 449884}, NULL) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}], 6, 30000) = 0
gettimeofday({1172324769, 455873}, NULL) = 0
time(NULL) = 1172324769
time(NULL) = 1172324769
gettimeofday({1172324769, 456281}, NULL) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}], 6, 30000) = 0
gettimeofday({1172324799, 462835}, NULL) = 0
time(NULL) = 1172324799
time(NULL) = 1172324799
gettimeofday({1172324799, 463245}, NULL) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}], 6, 28260) = 0
gettimeofday({1172324827, 730052}, NULL) = 0
gettimeofday({1172324827, 730189}, NULL) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}], 6, 1) = 0
gettimeofday({1172324827, 738199}, NULL) = 0
gettimeofday({1172324827, 738329}, NULL) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}], 6, 1725) = 0
gettimeofday({1172324829, 470283}, NULL) = 0
time(NULL) = 1172324829
time(NULL) = 1172324829
gettimeofday({1172324829, 470689}, NULL) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}], 6, 30000) = 0
gettimeofday({1172324859, 478181}, NULL) = 0
time(NULL) ...

> Thank you for your work on that. Marking unconfirmed. What
> is that " relict" program doing?

The "relict" process is /usr/lib/libgconf2-4/gconfd-2 that runs for the previously logged-in user, and I don't know what it's doing but it eats all the CPU activity (100%).

Please also note that my above post (providing the backtrace and strace) was a little overzealous -- in my effort to get a useful backtrace (with the built debug-packages) I have been unable to preproduce the described situation since the bugreport, but when I noticed the mentioned 100% CPU activity today I thought that the bug went back -- checked via ps to see if the duplicate gconfd-2 is running and then followed the steps from the wiki to obtain a backtrace of gconfd2. But when I just checked which process has 100% CPU usage it turned out to be... ekiga, NOT gconfd2! But I hope the info was useful after all.

Do you still get the bug?

No, since building & installing the debug packages, I'm still waiting to reproducing this bug...

We are closing this bug for now, please feel free to re open it if you can reproduce it and provide us more info. Thas in advance.