update-notifier leads to 100% cpu usage

Thanks for your bugreport.

Can you please run:
$ strace -p `pidof update-notifier` 2> u-n.log

let it run for a couple of seconds and attach the u-n.log file to this bugreport?

(In reply to comment #1)
> Thanks for your bugreport.
>
> Can you please run:
> $ strace -p `pidof update-notifier` 2> u-n.log
>
> let it run for a couple of seconds and attach the u-n.log file to this bugreport?
Sure, here it is, but I'm afraid it doesn't say very much, or did I so something
wrong?
Here's all I get:

Process 3976 attached - interrupt to quit
Process 3976 detached

(In reply to comment #2)
> (In reply to comment #1)
> > Can you please run:
> > $ strace -p `pidof update-notifier` 2> u-n.log
> >
> > let it run for a couple of seconds and attach the u-n.log file to this
bugreport?
> Sure, here it is, but I'm afraid it doesn't say very much, or did I so something
> wrong?
> Here's all I get:
>
> Process 3976 attached - interrupt to quit
> Process 3976 detached

So the file u-n.log does only contain these lines? Nothing more? And still
update-notifier uses 100% cpu? And nothing printed on the terminal? This the
problem reproducable (that is, if you kill update-notifier and restart it, does
it still have 100% cpu usage)?

Thanks,
 Michael

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Can you please run:
> > > $ strace -p `pidof update-notifier` 2> u-n.log
> > >
> > > let it run for a couple of seconds and attach the u-n.log file to this
> bugreport?
> > Sure, here it is, but I'm afraid it doesn't say very much, or did I so something
> > wrong?
> > Here's all I get:
> >
> > Process 3976 attached - interrupt to quit
> > Process 3976 detached
>
> So the file u-n.log does only contain these lines? Nothing more? And still
> update-notifier uses 100% cpu? And nothing printed on the terminal? This the
> problem reproducable (that is, if you kill update-notifier and restart it, does
> it still have 100% cpu usage)?
>
> Thanks,
> Michael
>
>

Yes, unfortunately that's all I get if I run the command you posted.
Do you want me to run something like strace update-notifier 2>u-n.log? I get a
host of output that way but I fear it's to much to post here.
I also don't get anything on the terminal when I start update-notifier there, no
error message whatsoever, but it is reproducible, that is if I kill it and start
it again the cpu will be used 100% again.
Also others seem to have the same problem, for example:
http://ubuntuforums.org/showthread.php?t=59409
And maybe this one too:
http://ubuntuforums.org/showthread.php?t=58867

(In reply to comment #4)
[..]
> Yes, unfortunately that's all I get if I run the command you posted.
> Do you want me to run something like strace update-notifier 2>u-n.log? I get a
> host of output that way but I fear it's to much to post here.
> I also don't get anything on the terminal when I start update-notifier there, no
> error message whatsoever, but it is reproducible, that is if I kill it and start
> it again the cpu will be used 100% again.

Then please do a strace, let it run for a couple of seconds and if it's not too
big, either upload it to a webpage or attach it to this bugreport. I wonder if
it is a ppc specific problem because I'm unable to reproduce it here with my
i386 system.

> Also others seem to have the same problem, for example:
> http://ubuntuforums.org/showthread.php?t=59409

This one is a ppc as well.

> And maybe this one too:
> http://ubuntuforums.org/showthread.php?t=58867

This one has not writen his arch. Could you please ask what arch he is using
(sorry, I'm not a memeber of the forums).

Thanks,
 Michael

(In reply to comment #5)

> Then please do a strace, let it run for a couple of seconds and if it's not too
> big, either upload it to a webpage or attach it to this bugreport.

Arrgh, the output is to big to post here and I don't currently have any webspace
where I could post it.
Would it be ok if I emailed it to you?

Created an attachment (id=3368)
strace output

Output from strace update-notifier 2>u-n3.log

(In reply to comment #7)
> Created an attachment (id=3368) [edit]
> strace output

How long did it run? Does the last message always repeats in the log and you
just cut the rest?

Created an attachment (id=3369)
strace output2

(In reply to comment #9)
> Created an attachment (id=3369) [edit]
> strace output2
>

sorry, seems I'm to dumb to use bugzilla.
The first run was very short, about a second, now I waited for several seconds.
And yes, the message seems to get repeated.

Thanks

Can you please send me the file:

/var/lib/update-notifier/user.d//notification-2.6.12-7-powerpc

and also check if removing that file helps?

Created an attachment (id=3373)
notification-2.6.12-6-powerpc

removing the file and also removing notification-2.6.12-6-powerpc didn't help
though.

I'm sorry, I removed the file befor attaching it, today I really am an idiot,
sorry again.
Anyway I now attached the previous file. Hope this helps.

(In reply to comment #12)
> Created an attachment (id=3373) [edit]
> notification-2.6.12-6-powerpc
>
> removing the file and also removing notification-2.6.12-6-powerpc didn't help
> though.

Thanks!

> I'm sorry, I removed the file befor attaching it, today I really am an idiot,
> sorry again.

No worries. If it didn't remove the problem it wasn't the cause of the problem
so it's not that importent.

> Anyway I now attached the previous file. Hope this helps.

Could you do another strace for me please? Run it for ~30 secs and gzip it
please. If it's then less then 2Mb,
please attach it, I hope that gives me a better idea what the problem might be.

Thanks (and sorry that it takes so long to get a idea what the problem might be),
 Michael

Created an attachment (id=3374)
strace output3

Ok, here's the strace output.
I don't know if it is significant, but I just noticed that no matter how long I
let strace run the log files seem to stop filling at some point as all of them
are now 266k big. Strange.

No need to be sorry. Thank you for your work!

(In reply to comment #14)
> Ok, here's the strace output.
> I don't know if it is significant, but I just noticed that no matter how long I
> let strace run the log files seem to stop filling at some point as all of them
> are now 266k big. Strange.

Thanks. So the logfile does not fill up anymore, but update-notifier still spins
at 100%? And removing everything in /var/lib/update-notifer/user.d does not help
at all? Strange ...

(In reply to comment #15)

> Thanks. So the logfile does not fill up anymore, but update-notifier still spins
> at 100%? And removing everything in /var/lib/update-notifer/user.d does not help
> at all? Strange ...
>
Exactly. Though update-notifier doesn't use 100% itself to be more precise, it
just take what is available so that the cpu is used 100% all the time.

I'm a bit in the dark about this bug right now. Do you see in "top" that the
process id (pid) of update-notifier is running at 100% and at the same time
staceing the same processid does not show activity? That is really odd. Maybe it
a subprocess started by update-notifier that causes the trouble?

(In reply to comment #17)
> I'm a bit in the dark about this bug right now. Do you see in "top" that the
> process id (pid) of update-notifier is running at 100% and at the same time
> staceing the same processid does not show activity? That is really odd. Maybe it
> a subprocess started by update-notifier that causes the trouble?

Ok, reading my description of the problem I see that it wasn't very clear, so
let me try again.
What I see is update-notifier taking up all the CPU that is left by the other
processes running all the time.
Let me give you some examples to make this clearer, if the other processes take
up 50% of the CPU update-notifier will use 50%, if the other processes use only
10% of the CPU, update-notifier will use 90% of it. This of course leads to the
CPU being used 100% all the time.

You are right, I'm seeing what I described above while at the same time strace
doesn't give me any more output. It always stops at:
read(16, "notification-2.6.12-6-powerpc 11"..., 4096) = 43
read(16, "", 4096) = 0
close(16) = 0
munmap(0x30237000, 4096) = 0
open("/home/ralph/.update-notifier/hooks_seen", O_RDONLY) = 16
fstat64(16, {st_mode=S_IFREG|0644, st_size=86, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x30237000
read(16, "notification-2.6.12-6-powerpc 11"..., 4096) = 86
read(16, "", 4096) = 0
close(16) = 0
munmap(0x30237000, 4096) = 0
open("/var/lib/update-notifier/user.d/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 16
fstat64(16, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(16, F_SETFD, FD_CLOEXEC) = 0
getdents64(16, /* 2 entries */, 4096) = 48
getdents64(16, /* 0 entries */, 4096) = 0
close(16) = 0

But despite no apparent activity according to strace, update-notifier still uses
all the CPU available. (And I double-checked /var/lib/update-notifier/user.d/ is
indeed empty)

> [...]
> read(16, "notification-2.6.12-6-powerpc 11"..., 4096) = 43
> read(16, "", 4096) = 0
> close(16) = 0
> munmap(0x30237000, 4096) = 0
> open("/home/ralph/.update-notifier/hooks_seen", O_RDONLY) = 16
> fstat64(16, {st_mode=S_IFREG|0644, st_size=86, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x30237000
> read(16, "notification-2.6.12-6-powerpc 11"..., 4096) = 86
> read(16, "", 4096) = 0
> close(16) = 0
> munmap(0x30237000, 4096) = 0
> open("/var/lib/update-notifier/user.d/",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 16
> fstat64(16, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> fcntl64(16, F_SETFD, FD_CLOEXEC) = 0
> getdents64(16, /* 2 entries */, 4096) = 48
> getdents64(16, /* 0 entries */, 4096) = 0
> close(16) = 0

Good news and dooh. Seeing that it somehow tried to access
notification-2.6.12-6-powerpc though I had deleted the file, I know deleted
~/.update-notifier/ and now it works like a charm, so I think your first thought
that it had something to do with the files in /var/lib/update-notifier/user.d/
was right after all.

Thanks a lot for this update.

You have deleted the files under ~/.update-notifer already? I would have loved
to get them so that I can try to understand the problem better. If you still
have them available somewhere, please attach them to this bugreport.

Cheers,
 Michael

Created an attachment (id=3382)
file causing the problem

So, as you might have noticed, I sometimes do very stupid things, so yes, I
simply deleted the directory.

However, I was able to recreat the problem and the file that seems to cause the
problem (there is and was just one file under .update-notifier, namely
hooks_seen) by reverting back to an old kernel and then updating again.

Hope this helps.

I'm on ppc (mac mini) running Breezy (latest updates), installed from Colony3 cd.
I had the exact same problem.
Deleting the file "~/.update-notifer/hooks_seen" as you said solved the problem.

You wanted the files in "~/.update-notifer"?
I only had 1 file in that folder. (hooks_seen)

If it is to any help, the content of that file was:

notification-2.6.12-6-powerpc 1124802716 0
notification-2.6.12-7-powerpc 1124470103 0

I'm having the same problem, using kernel 2.6.10-5-k7 on an Athlon XP.
Unfortunately ~/.update-notifier is empty on this machine.

If you (or anyone else) can still reproudce this bug (I can't unfortunately),
please run the following commands in a terminal:
$ gdb -p `pidof update-notifier`
[you may have to press enter a few times]
(gdb) where

and paste me the output.

Thanks,
 Michael

*** Bug 21176 has been marked as a duplicate of this bug. ***

(In reply to comment #24)
> If you (or anyone else) can still reproudce this bug (I can't unfortunately),
> please run the following commands in a terminal:
> $ gdb -p `pidof update-notifier`
> [you may have to press enter a few times]
> (gdb) where
>
> and paste me the output.
>
> Thanks,
> Michael

I have the same problem described in this bug report.
If deleted, the hooks_seen file reappears after reboot.

The command above just returns this:

$ gdb -p `pidof update-notifier`
gdb: option `-p' requires an argument
Use `gdb --help' for a complete list of options.

running breezy ppc on g3 ibook 2.2

(In reply to comment #26)
> (In reply to comment #24)
[..]
> I have the same problem described in this bug report.
> If deleted, the hooks_seen file reappears after reboot.
>
> The command above just returns this:
>
> $ gdb -p `pidof update-notifier`
> gdb: option `-p' requires an argument
> Use `gdb --help' for a complete list of options.

Hm, can you please check (e.g. by runing System tools/System Monitor) that it's
really update-notifier that is causing the 100% cpu and then what "pid"
update-notifier is (click on "More info" in System Montior). Then run
$ gdb -p "pid"
(replace "pid" with the pid number (usually something like 9495).
(gdb) where

If it is not update-notifier that causes the 100% cpu, I would be interessted
what process it was.

Thanks,
 Michael

(In reply to comment #28)

> Hm, can you please check (e.g. by runing System tools/System Monitor) that it's
> really update-notifier that is causing the 100% cpu and then what "pid"
> update-notifier is (click on "More info" in System Montior). Then run
> $ gdb -p "pid"
> (replace "pid" with the pid number (usually something like 9495).
> (gdb) where
>
> If it is not update-notifier that causes the 100% cpu, I would be interessted
> what process it was.
>
> Thanks,
> Michael

Yes, it is the update-notifier alright.
I guess you only want the (gdb) where output, so here you go:

(gdb) where
#0 0x0ed7ccd0 in g_list_length () from /usr/lib/libglib-2.0.so.0
#1 0x10008fbc in check_update_hooks ()
#2 0x10009628 in hook_tray_icon_init ()
#3 0x100059ac in fam_init ()
#4 0x10005bc8 in main ()

(tell me if you want the whole gdb -p output. It did not seem that relevant at
this point...)

Created an attachment (id=3885)
full output of requested test

almost filed a new bug, as the side effect of this is that the fan runs full
blast. just remembered at the last minute to check the system load. my machine
is a 1.25Ghz G4 iBook.

It looks like this problem is finally fixed. Please test the debs in:

http://people.ubuntu.com/~mvo/update-notifier/

I'll probably upload the version tonight, so far I got a positive report from
"magnon" (thanks!).

I uploaded update-notifier_0.40.9 into the archive. It should fix the loop
problem, please reopen if you still have the problem with the updated version.

*** Bug 22366 has been marked as a duplicate of this bug. ***

(In reply to comment #33)
> *** Bug 22366 has been marked as a duplicate of this bug. ***

Ok, this is strange. I actually rebooted after updating (because the update
included a new kernel), and I saw the result mensioned in bug report 16159.
After your reply, I rebooted again, and now the cpu is back to normal.

Sorry if I caused trouble.

Anyhow, I did a "gdb -p" and a "(gdb) where". The results follow below (probably
not needed, but I attach them anyway):

(gdb) where
#0 0x0ec33ca4 in strcmp () from /lib/libc.so.6
#1 0x10007994 in compare_hook_func ()
#2 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
#3 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
#4 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
#5 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
#6 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
#7 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
#8 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
#9 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
Previous frame inner to this frame (corrupt stack?)

(In reply to comment #34)
> (In reply to comment #33)
> > *** Bug 22366 has been marked as a duplicate of this bug. ***
>
> Ok, this is strange. I actually rebooted after updating (because the update
> included a new kernel), and I saw the result mensioned in bug report 16159.
> After your reply, I rebooted again, and now the cpu is back to normal.
>
> Sorry if I caused trouble.
>
> Anyhow, I did a "gdb -p" and a "(gdb) where". The results follow below (probably
> not needed, but I attach them anyway):
>
> (gdb) where
> #0 0x0ec33ca4 in strcmp () from /lib/libc.so.6
> #1 0x10007994 in compare_hook_func ()
> #2 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
> #3 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
> #4 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
> #5 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
> #6 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
> #7 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
> #8 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
> #9 0x0ed7cb80 in g_list_find_custom () from /usr/lib/libglib-2.0.so.0
> Previous frame inner to this frame (corrupt stack?)
>

 Ok, I looked into it some more. The bug is still there, it was running the gdb
that put the cpu back to normal. after quitting from (gdb)
 update-notifier starts filling the remaining cpu again...

(In reply to comment #35)
> (In reply to comment #34)
> > (In reply to comment #33)
> Ok, I looked into it some more. The bug is still there, it was running the gdb
> that put the cpu back to normal. after quitting from (gdb)
> update-notifier starts filling the remaining cpu again...

Can you still reproduce it so that I can send you new binaries to test? I assume
you run ppc as well?

Cheers,
 Michael

(In reply to comment #36)
> Can you still reproduce it so that I can send you new binaries to test? I assume
> you run ppc as well?

I noticed this bug on my dad's machine, an athlon 900mhz, so this bugs also hits
x86!
Interestingly, it does not appear on my laptop or my own machine (amd64). All
three machines are upgrades from hoary.

update-notifier takes up 100%CPU when it is about to show a post-installation
message. System is Ubuntu-Breezy-PPC; update-notifier package version is
0.40.10. update-notifier worked fine before todays update.

This is the gdb "where" output:
(gdb) where
#0 0x0ed7cca4 in g_list_first () from /usr/lib/libglib-2.0.so.0
#1 0x10008148 in show_next_hook ()
#2 0x10008844 in show_hooks ()
#3 0x10008950 in show_hooks ()
#4 0x0f91a17c in _gtk_marshal_BOOLEAN__BOXED ()
   from /usr/lib/libgtk-x11-2.0.so.0
#5 0x0f91a17c in _gtk_marshal_BOOLEAN__BOXED ()
   from /usr/lib/libgtk-x11-2.0.so.0
#6 0x0f91a17c in _gtk_marshal_BOOLEAN__BOXED ()
   from /usr/lib/libgtk-x11-2.0.so.0
[...continues corrupt stack?]

Created an attachment (id=4123)
hooks_seen file causing 100% CPU

Removing hooks_seen solves the issue for me. Attached is the offending file

(In reply to comment #39)
> Created an attachment (id=4123) [edit]
> hooks_seen file causing 100% CPU
>
> Removing hooks_seen solves the issue for me. Attached is the offending file

Does moving the attached hook file back to "hooks_seen" make the bug reappear?
If so, you
you please check if
http://people.ubuntu.com/~mvo/update-notifier/update-notifier_0.40.10.mvo1_powerpc.deb
fixes the problem?

(In reply to comment #40)
> Does moving the attached hook file back to "hooks_seen" make the bug reappear?
> If so, you
> you please check if
>
http://people.ubuntu.com/~mvo/update-notifier/update-notifier_0.40.10.mvo1_powerpc.deb
> fixes the problem?

This package will also log stuff into .xsession-errors. If someone can reproduce
the error I would love to get the debug output from this package.

update-notifier got caught in an infinite loop today for me on an i686 machine.
 An strace snippet from the middle of the loop is at:

http://cerberus.0c3.net/~adconrad/u-n.trace.gz

This is probably not the same bug (then again, half the "me too"s in here may
not be the same bug), but this seems to be the placeholder bug for
"update-notifier eats all my CPU, oh noes!", so here you go. :)

(In reply to comment #42)
> update-notifier got caught in an infinite loop today for me on an i686 machine.
> An strace snippet from the middle of the loop is at:
>
> http://cerberus.0c3.net/~adconrad/u-n.trace.gz
>
> This is probably not the same bug (then again, half the "me too"s in here may
> not be the same bug), but this seems to be the placeholder bug for
> "update-notifier eats all my CPU, oh noes!", so here you go. :)

Right. This one looks like dbus gone mad. fd3 is the descriptor that connects to
the system bus. Oh well.

If this doesn't have an absolutely simple and obvious fix, it's unlikely that it
will make the 5.10 release. Michael?

(In reply to comment #44)
> If this doesn't have an absolutely simple and obvious fix, it's unlikely that it
> will make the 5.10 release. Michael?

I was never able to reproduce the problem here myself. The original problem may
very well be fixed already. The problem Adam Conrad describe looks like a dbus
problem. I haven't found a way to reproduce it (tried various stuff like
restarting/reinstall dbus, update-notifier, both etc).

I remove the target milestone for now because this bug (or parts of it) are
probably already fixed but I'm still not sure what's left.

I've just hit this problem on i686. After reading through this bug I collected
some info which I am about to attach.

I only had hooks_seen in ~/.update-notifier.

The strace output looks to me like it is looking for some unavailable resource
and, as all the output was similar, I've only attached a small extract. I have
a few seconds worth if that would help.

Deleting hooks_seen did nothing. Killing and restarting then left me with
normal cpu usage. I then copied hooks_seen back to ~/.update-notifier and
restarted it again. My cpu usage stayed sane. Unfortunately this could make
reproducing it again tricky :(

When doing the gdb stuff, I think I noticed that my cpu monitor dropped to
normal after running "where" and rose back to 100% again when I quit gdb. Just
caught it out of the corner of my eye - didn't think to look, sorry.

Any more info wanted just ask and I'll see what I can do.

Created an attachment (id=4834)
GK's hook_seen

Created an attachment (id=4835)
GK's top

Created an attachment (id=4836)
GK's strace extract

Created an attachment (id=4837)
GK's gdb where

Hi there!

> If you (or anyone else) can still reproudce this bug (I can't unfortunately),
> please run the following commands in a terminal:
> $ gdb -p `pidof update-notifier`
> [you may have to press enter a few times]
> (gdb) where
> and paste me the output.

Okay, after a long time without problems, it finally happened again.
I'm running Breezy 5.10 on an Athlon XP.
Here's the gdb output:

#0 0xffffe410 in ?? ()
#1 0xbf94de48 in ?? ()
#2 0xffffffff in ?? ()
#3 0x00000001 in ?? ()
#4 0xb74220bd in poll () from /lib/tls/i686/cmov/libc.so.6
#5 0xb76a2010 in _XEnq () from /usr/lib/libX11.so.6
#6 0xb76a2462 in _XRead () from /usr/lib/libX11.so.6
#7 0xb76a33d8 in _XReply () from /usr/lib/libX11.so.6
#8 0xb769b07b in XSync () from /usr/lib/libX11.so.6
#9 0x0804da1a in egg_tray_icon_get_type ()
#10 0x0804da79 in egg_tray_icon_get_type ()
#11 0x0804dbdb in egg_tray_icon_get_type ()
#12 0x0804d813 in egg_tray_icon_get_type ()
#13 0xb78782bb in gdk_events_pending () from /usr/lib/libgdk-x11-2.0.so.0
#14 0xb7878a91 in gdk_x11_register_standard_event_type () from
/usr/lib/libgdk-x11-2.0.so.0
#15 0xb787a9b9 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0
#16 0xb787ab02 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0
#17 0xb74c74ee in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#18 0xb74ca4f6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#19 0xb74ca7e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#20 0xb7af6e65 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#21 0x0804d46f in main ()

As soon as I ran the "where" command, the CPU usage dropped back to zero and
stayed there.
The only content in ~/.update-notifier/hooks_seen is
"language-pack-en_20050701 1130060798 0".

Hope this will help to catch this bug :-).

Merry christmas everyone!
Peter

> As soon as I ran the "where" command, the CPU usage dropped back to zero and
> stayed there.

More precisely, it went up again to 100% after I quit gdb.
(Seems gdb only stopped the attached process.)
Removing hooks_seen didn't help, I needed to kill update-notifier.
Running update-notifier again with the previous content of hooks_seen *did not*
reproduce the CPU consumption.

Any news on this? Did it happend recently for you?

I unset the milestone because I got no reports about this for some time.

I cannot reproduce it currently, as explained in bug #45477.

I'm not able to reproduce this report anymore and we have not got new reports about this problem since some time.

Hence I will close this bug. Please reopen if you experience this problem again.

Cheers,
 Mcihael

I am having the same problem on and amd64 with the latest jaunty packages as of 2009-08-19. It's actually been like that since intrepid, that at times the update-notifier sucks up all remaining CPU on one of the cores. Doesn't happen regularly and I haven't found a pattern yet.

I have moved the files from /var/lib/update-notifier/user.d out of the way and will perform the steps described in comment 24 when I see this again.

Thank you for reporting this bug.

Does this occur in Lucid?

I haven't experienced it with Lucid on 2 different machines. If my memory isn't playing tricks on me, I think I did see it once or twice with Karmic.

Does it occur in Maverick?

Please open a new bug, if you hit this issue on a SUPPORTED release. Thanks.