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.
** Changed in: gconf2 (Ubuntu)
Status: New = Invalid
--
gconfd-2 doesn't stop for previous user logged into GNOME
https://bugs.launchpad.net/bugs/85521
You
Do you still get the bug?
--
gconfd-2 doesn't stop for previous user logged into GNOME
https://bugs.launchpad.net/bugs/85521
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
No, since building installing the debug packages, I'm still waiting to
reproducing this bug...
--
gconfd-2 doesn't stop for previous user logged into GNOME
https://bugs.launchpad.net/bugs/85521
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug
Thank you for your work on that. Marking unconfirmed. What is that
relict program doing?
** Changed in: gconf2 (Ubuntu)
Status: Needs Info = Unconfirmed
--
gconfd-2 doesn't stop for previous user logged into GNOME
https://launchpad.net/bugs/85521
--
desktop-bugs mailing list
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
[EMAIL PROTECTED]:~$ sudo strace -p 7238
Process 7238 attached - interrupt to quit
gettimeofday({1172324704,
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%).
--
gconfd-2 doesn't stop for
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
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
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
** Changed in: gconf2 (Ubuntu)
Importance: Undecided = Low
Assignee:
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
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
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
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?
--
gconfd-2
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,
14 matches
Mail list logo
