dbus-daemon memory leak

[Angus]

Binary package hint: dbus

I have a plasmoid that polls Amarok 2 for information through dbus. After several hours, I find that dbus-daemon is using several hundred megabytes of RAM. At last check it was using 800 MB. The only solution is to log out and log back in. These are the calls that I'm making to dbus:

qdbus org.kde.amarok /Player GetMetadata
qdbus org.kde.amarok /Player PositionGet
dbus-send --dest='org.kde.amarok' --print-reply /Player org.freedesktop.MediaPlayer.GetStatus

dbus:
  Installed: 1.2.4-0ubuntu1
  Candidate: 1.2.4-0ubuntu1
  Version table:
 *** 1.2.4-0ubuntu1 0
        500 http://us.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

Description: Ubuntu 8.10
Release: 8.10

[Eduardo Durany Fernández (edurany)]

Confirmed in Intrepid. After 3 days, dbus-daemon is taking more than 300MB of system memory. Something is wrong with this program.

[Brent Cook (busterbcook)]

If I run kontact, dbus-daemon uses over 2 GB of ram and 100% cpu after a day. Running dbus-monitor shows a constant stream of activity from akonadi. If I kill kontact and the various akonadi services, things go back idle. This is with the latest jaunty, and has been occuring for a couple of weeks.

method call sender=:1.812 -> dest=org.freedesktop.DBus serial=21 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/ManagerIface_contact',interface='org.kde.KResourcesManager',member='signalKResourceDeleted'"
method call sender=:1.812 -> dest=org.freedesktop.DBus serial=22 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.freedesktop.Akonadi.Control"
method call sender=:1.812 -> dest=org.freedesktop.DBus serial=23 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.freedesktop.Akonadi"
method call sender=:1.812 -> dest=org.freedesktop.DBus serial=24 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.freedesktop.Akonadi.Control"
method call sender=:1.812 -> dest=org.freedesktop.DBus serial=25 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.freedesktop.Akonadi"
method call sender=:1.812 -> dest=org.freedesktop.DBus serial=26 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.freedesktop.Akonadi"
method call sender=:1.812 -> dest=org.freedesktop.DBus serial=27 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.freedesktop.Akonadi"
method call sender=:1.812 -> dest=org.freedesktop.DBus serial=28 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.freedesktop.Akonadi.Control"
method call sender=:1.812 -> dest=org.freedesktop.DBus serial=29 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.freedesktop.Akonadi"
method return sender=:1.812 -> dest=:1.64 reply_serial=16814
   string "Birthdays"
method return sender=:1.812 -> dest=:1.64 reply_serial=16827
   int32 0 ...

[James Andrewartha (trs80)]

Not sure if it's related, but I have one hardy server where dbus-daemon gradually increases its memory usage over time. The only thing using dbus on the server is avahi-daemon.

[tak1150 (tsuyama)]

I have the same problem as well.
Running Intrepid with Compiz.

I have not been able to determine which program this dbus problem is related to. It happened a few times while I was using OpenOffice 3, banshee, sound-juicer, liferea, firefox, evolution, and others.
dbus-daemon all of a sudden takes up too much of CPU and the computer slows down to a point I can't do anything. The only way to get out of it was to do:

sudo /etc/init.d/dbus restart
sudo /etc/init.d/gdm restart

It happens every 1 or 2 hours. I just installed Intrepid and I like it. I do not want to go back to Lenny. Please help!
Inspiron 5150 NVIDIA FX5200, pentium 4

[habtool (clive-wagenaar)]

This is happening on Jaunty for me too

[habtool (clive-wagenaar)]

screenshot of dbus-daemon using 438MG memory.
machine uptime was only 20 hours.

apt-cache policy dbus
dbus:
  Installed: 1.2.12-0ubuntu2
  Candidate: 1.2.12-0ubuntu2
  Version table:
 *** 1.2.12-0ubuntu2 0
        500 http://gb.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

[habtool (clive-wagenaar)]

I have now installed the RC of jaunty 9.04.
Installed all the extra programs I use.

The dbus-daemon run away memory leak is still here.

Rebooted and individually loaded the programs that I use and leave running..
After running each one I waited to see if dbus-daemon would start increasing memory usage.

On my install the culprit without a doubt is Akregator.

I now run all the programs I run overnight, (except akregator) this morning they are all stil running and no memory leaks.

Will stop using akregator till the leak is plugged.

akregator:
  Installed: 4:4.2.2-0ubuntu1
  Candidate: 4:4.2.2-0ubuntu1
  Version table:
 *** 4:4.2.2-0ubuntu1 0
        500 http://gb.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

[dark_construct (james-shredon)]

After upgrading to jaunty, I also have the dbus-daemon memory. I can see it increase in size.

I have narrowed it down to using dolphin and kate. I'm not sure if has anything to do with accessing ssh shares, samba shares, etc, because I access many drives with dolphin. Also, I have Kubunu installed as an addition to my regular Ubuntu. I did an upgrade to Juanty from Intrepid. I have the dame bug on both a 64 bit system and a 32 bit system.

[MCVF (marfol)]

Also have this problem in Jaunty. How do I notice? After few days without logging off my system uses 2GB of memory without any application running. Right now, dbus-daemon uses 668MB of resident memory. After relog, my system uses somewhere between 400-800MB with few running applications. I regularly use kile, rarely amarok.

[iron4o (ironsmile)]

Had the same ugly thing myself. Most of my KDE apps (akregator, amarok etc) would cause that dbus-daemon memory leak instantly.
The problem is now gone when I stopped the vino-server. Also, solves the problem described in that threat http://www.uluga.ubuntuforums.org/showthread.php?t=1125401 . I have no idea why that helped but I am much happier now.

[St Weiss (stweiss)]

Same situation here (Kubuntu Intrepid, dbus-daemon currently at 400M). Unfortunately the mentioned possible workarounds do nothing for me: I don't run vino-server or Akregator, I've disabled Akonadi, and I've stopped using Amarok due to this problem. This is really an unpleasant situation... I can't run most of the KDE goodness, and I have to logout/reboot every 1-2 days. Any clues about how to track this down or avoid it would be greatly appreciated.

[Hei Ku (asoliverez)]

I had the same leak and found it was the Oxygen System Monitor, querying several times per second for Amarok information, even if Amarok is not running.
Removing the system monitor from the desktop stopped the leak for me, at least for now.

[Scott James Remnant (Canonical) (canonical-scott)]

There's no particular proof that this is a memory leak.

Messages have a timeout attached to them, if an application sends messages in very quick succession, they will build up inside D-Bus while it waits for the timeout.

If an application continues to send messages, you'll just end up with more and more in its buffers.

If you kill the application repeatedly sending messages, D-Bus's memory increase should stop.

Obviously Linux applications never *give back* memory, but it shouldn't increase

[Hei Ku (asoliverez)]

It renders the machine unusable, and it will even prevent me from restarting kdm. So, if it is not a memory leak, it behaves like one, and whether it is a memory leak or not is just semantics. The problem should be fixed. If it's an excessive load that will render D-Bus unusable, then you have a target for a DoS attack.

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-07-15 at 12:27 +0000, Hei Ku wrote:

> It renders the machine unusable, and it will even prevent me from
> restarting kdm. So, if it is not a memory leak, it behaves like one, and
> whether it is a memory leak or not is just semantics. The problem should
> be fixed. If it's an excessive load that will render D-Bus unusable,
> then you have a target for a DoS attack.
>
I don't think you understand how Linux Virtual Memory works.

If you're having a problem right *now* where your machine is unusable,
and you think that D-Bus is causing it, please provide the output of
"ps avx"

Thanks,

Scott
--
Scott James Remnant
<email address hidden>

[Hei Ku (asoliverez)]

Don't patronize me, please. I know that D-Bus shouldn't take 2GB of RAM and fill in all available swap space while sitting idle.

I don't have the same setup as when the bug was reported, but I will try to reproduce it and send the output of "ps avx"
Now, have you tried to reproduce it, or are you discussing semantics for the sake of it?

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-07-15 at 13:14 +0000, Hei Ku wrote:

> Don't patronize me, please. I know that D-Bus shouldn't take 2GB of RAM
> and fill in all available swap space while sitting idle.
>
Then prove it is.

Scott
--
Scott James Remnant
<email address hidden>

[James Andrewartha (trs80)]

root@quoll:~ # date;ps avx|grep dbus
Thu Jul 16 01:04:02 WST 2009
12667 ? Ss 0:00 0 346 102733 50456 0.6 /usr/bin/dbus-daemon --system
27136 pts/1 S+ 0:00 0 101 4166 940 0.0 grep dbus
root@quoll:~ # date;ps avx|grep dbus
Thu Jul 16 01:14:50 WST 2009
12667 ? Ss 0:00 0 346 102733 50456 0.6 /usr/bin/dbus-daemon --system
29668 pts/1 R+ 0:00 0 101 4162 832 0.0 grep dbus
root@quoll:~ # date;ps avx|grep dbus
Thu Jul 16 02:16:56 WST 2009
12667 ? Ss 0:00 0 346 109941 57480 0.7 /usr/bin/dbus-daemon --system
13688 pts/1 S+ 0:00 0 101 4166 932 0.0 grep dbus
root@quoll:~ # date;ps avx|grep dbus
Thu Jul 16 02:54:10 WST 2009
12667 ? Ss 0:00 0 346 114693 62076 0.7 /usr/bin/dbus-daemon --system
22685 pts/1 S+ 0:00 0 101 4166 936 0.0 grep dbus
root@quoll:~ # date;ps avx|grep dbus
Thu Jul 16 14:40:29 WST 2009
12667 ? Ss 0:01 0 346 197329 142212 1.7 /usr/bin/dbus-daemon --system
20348 pts/1 S+ 0:00 0 101 4166 936 0.0 grep dbus

I've killed avahi-daemon and console-kit-daemon which are the only users of dbus on this system.

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-07-16 at 06:43 +0000, James Andrewartha wrote:

> root@quoll:~ # date;ps avx|grep dbus
> Thu Jul 16 01:04:02 WST 2009
> 12667 ? Ss 0:00 0 346 102733 50456 0.6 /usr/bin/dbus-daemon --system
> 27136 pts/1 S+ 0:00 0 101 4166 940 0.0 grep dbus
> root@quoll:~ # date;ps avx|grep dbus
> Thu Jul 16 01:14:50 WST 2009
> 12667 ? Ss 0:00 0 346 102733 50456 0.6 /usr/bin/dbus-daemon --system
> 29668 pts/1 R+ 0:00 0 101 4162 832 0.0 grep dbus
> root@quoll:~ # date;ps avx|grep dbus
> Thu Jul 16 02:16:56 WST 2009
> 12667 ? Ss 0:00 0 346 109941 57480 0.7 /usr/bin/dbus-daemon --system
> 13688 pts/1 S+ 0:00 0 101 4166 932 0.0 grep dbus
> root@quoll:~ # date;ps avx|grep dbus
> Thu Jul 16 02:54:10 WST 2009
> 12667 ? Ss 0:00 0 346 114693 62076 0.7 /usr/bin/dbus-daemon --system
> 22685 pts/1 S+ 0:00 0 101 4166 936 0.0 grep dbus
> root@quoll:~ # date;ps avx|grep dbus
> Thu Jul 16 14:40:29 WST 2009
> 12667 ? Ss 0:01 0 346 197329 142212 1.7 /usr/bin/dbus-daemon --system
> 20348 pts/1 S+ 0:00 0 101 4166 936 0.0 grep dbus
>
> I've killed avahi-daemon and console-kit-daemon which are the only users
> of dbus on this system.
>
Thanks, you'll need a bit of finesse to do this, but could you kill the
dbus-daemon and run under massif (part of valgrind):

  valgrind --tool=massif /usr/bin/dbus-daemon --system

This will generate a massif.out file.

Scott
--
Scott James Remnant
<email address hidden>

[James Andrewartha (trs80)]

OK, I've done this and there's a massif.out, but it's not being added to even though dbus' memory usage is increasing:

root@quoll:~ # date;ps xva|grep dbus
Thu Jul 16 22:39:13 WST 2009
14241 pts/1 S+ 0:00 0 101 4162 840 0.0 grep dbus
26826 ? Ss 0:01 0 1461 126526 51296 0.6 /usr/bin/valgrind.bin --tool=massif /usr/bin/dbus-daemon --system
root@quoll:~ # date;ps xva|grep dbus
Thu Jul 16 23:05:56 WST 2009
21914 pts/1 S+ 0:00 0 101 4162 852 0.0 grep dbus
26826 ? Ss 0:02 0 1461 134718 56164 0.6 /usr/bin/valgrind.bin --tool=massif /usr/bin/dbus-daemon --system
root@quoll:~ # ls -l massif.out.26824
-rw------- 1 root root 209304 2009-07-16 19:17 massif.out.26824

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-07-16 at 15:07 +0000, James Andrewartha wrote:

> OK, I've done this and there's a massif.out, but it's not being added to
> even though dbus' memory usage is increasing:
>
You need to terminate the dbus process, and then attach the massif.out
file ;-)

 status incomplete

Scott
--
Scott James Remnant
<email address hidden>

[James Andrewartha (trs80)]

Permissions fail:
==26826== error: can't open output file '/root/massif.out.26824'
==26826== ... so profiling results will be missing.
I'll try again and set the ownership to messagebus on massif.out this time.

[Scott James Remnant (Canonical) (canonical-scott)]

Thanks, here's that re-printed

[Scott James Remnant (Canonical) (canonical-scott)]

    MB
9.547^ ,,
     | ,,@@@#
     | ,,,@@@@@@#
     | ,,@@@@@@@@@@#
     | .@@@@@@@@@@@@@@#
     | ,.@::@@@@@@@@@@@@@@#
     | .@:@:@::@@@@@@@@@@@@@@#
     | . :: :@:@:@::@@@@@@@@@@@@@@#
     | ,@: :: :@:@:@::@@@@@@@@@@@@@@#
     | ..::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | ..::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | .::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | , : :::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | ,::@ : :::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | ,@@ @::@ : :::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | .@@@@ @::@ : :::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | .@: :@@@@ @::@ : :::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | ..:@ :@: :@@@@ @::@ : :::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | .: :::@ :@: :@@@@ @::@ : :::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
     | .: ::: :::@ :@: :@@@@ @::@ : :::::::::::@@: :: :@:@:@::@@@@@@@@@@@@@@#
   0 +----------------------------------------------------------------------->Mi
     0 119.3

Well, that's quite clearly a memory leak, isn't it ;-)

The culprint function (93.58%) of the allocs is getgrouplist (initgroups.c:157)

This leak is one we fixed quite some time ago:

dbus (1.2.1-2) unstable; urgency=low

  [ Sjoerd Simons ]
  * debian/rules: Disable the disabling of the userdb cache. No other
    distribution disables it and it is somewhat buggy (Thanks to Scott James
    Remnant for pointing out this issue)

 -- Sjoerd Simons <email address hidden> Sat, 26 Apr 2008 12:41:47 +0200

I guess we never backported that one to hardy.

[Scott James Remnant (Canonical) (canonical-scott)]

Note that this clearly isn't the original reporter's problem, since the version he is using is later

[Hei Ku (asoliverez)]

I tried to kill dbus-daemon, but KWin died on me and it killed my whole session. How can I do it gracefully?

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-07-17 at 02:54 +0000, Hei Ku wrote:

> I tried to kill dbus-daemon, but KWin died on me and it killed my whole
> session. How can I do it gracefully?
>
You can't, I'm afraid.

Scott
--
Scott James Remnant
<email address hidden>

[James Andrewartha (trs80)]

So are you going to fix the memory leak in hardy, or should I open a new bug asking for an SRU?

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-07-22 at 05:46 +0000, James Andrewartha wrote:

> So are you going to fix the memory leak in hardy, or should I open a new
> bug asking for an SRU?
>
If you'd like an SRU, the procedure for doing so is here:
http://wiki.ubuntu.com/StableReleaseUpdates

(note it doesn't require that you open a new bug, just a new task on
this one)

Scott
--
Scott James Remnant
<email address hidden>

[James Andrewartha (trs80)]

A statement explaining the impact of the bug on users and justification for backporting the fix to the stable release:
Fixes memory leak

An explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix.

dbus (1.2.1-2) unstable; urgency=low

  [ Sjoerd Simons ]
  * debian/rules: Disable the disabling of the userdb cache. No other
    distribution disables it and it is somewhat buggy (Thanks to Scott James
    Remnant for pointing out this issue)

 -- Sjoerd Simons <email address hidden> Sat, 26 Apr 2008 12:41:47 +0200

A minimal patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first.
Attached

Detailed instructions how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. Please mark this with a line "TEST CASE:".
TEST CASE: Run dbus on hardy, watch memory increase.

A discussion of the regression potential of the patch and how users could get inadvertently affected.
Minimal, fix is obvious, upstream and tested in later versions.

[James Andrewartha (trs80)]

Let's try this again - use this patch.

[Khashayar Naderehvandi (khashayar)]

I know this bug is supposed to be fixed, but I'm sure I'm seeing it on Karmic. dbus-daemon is using ~800MB here. Everything matches what is described in this thread, so I've decided not to open a new bug.

How can I provide additional useful information about this leak?

[James Andrewartha (trs80)]

Khashayar: Run /etc/init.d/dbus stop, then
  valgrind --tool=massif /usr/bin/dbus-daemon --system
like I did, it'll create a massif.out file, which you'll need to chown to messagebus, then kill dbus-daemon and add it as an attachment. Since killing dbus takes out any application on a bus, you'll need to do all of these commands from a terminal, but in between you can log in via gdm/kdm as normal.

[Martin Pitt (pitti)]

The patch makes sense (I subscribed main sponsors), but it worries me that it is still perceived in Karmic (which doesn't disable the userdb cache). Is it confirmed that it is the very same problem?

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-07-29 at 09:13 +0000, Martin Pitt wrote:

> The patch makes sense (I subscribed main sponsors), but it worries me
> that it is still perceived in Karmic (which doesn't disable the userdb
> cache). Is it confirmed that it is the very same problem?
>
I've not seen any evidence of a true leak in karmic.

You can obviously cause the dbus-daemon to increase its memory usage by
sending a vast volume of messages, but massif shows it as freed memory
afterwards.

Scott
--
Scott James Remnant
<email address hidden>

[Martin Pitt (pitti)]

Thanks Scott for the clarification. So I close the Karmic task, and any memory leak still visible in Karmic should get a new bug report.

[Martin Pitt (pitti)]

This is a pretty intrusive change, though, and I wouldn't accept it for intrepid or jaunty. However, with hardy being LTS it will stay around for a while, so with thorough testing the risk is manageable with proper testing IMHO.

I'd like this to stay in -proposed for at least two weeks, and get at least three "works for me" confirmations.

[Martin Pitt (pitti)]

Sponsored. Colin, Steve, can you please process?

[Khashayar Naderehvandi (khashayar)]

About the leak I saw in Karmic, I couldn't reproduce it with valgrind, so no evidence from my side.
For what it's worth, dbus' ~800MB memory usage was during Nepomuk's initial index of my ~53000 files. Subsequent indexes and crawls didn't cause dbus to fill up my RAM. So maybe it was just caused by a lot of messages, in which case I apologize for the noise.

[near (near)]

There's definitively something, but it appears only after a few weeks of using gnome. My main use is pidgin (always running) and several instances of epiphany (opened and closed several instances in a day).

I think the issue is with epiphany (or something close to it) :

* Here is a ps aux | grep dbus-daemon before :
none 5887 0.1 8.3 271544 255752 ? Ss Jul10 72:47 /usr/bin/dbus-daemon --fork --print-pid 6 --print-address 9 --session

* I run epiphany and browse several pages.

* Here is a ps aux | grep dbus-daemon again (only two minutes later) :
none 5887 0.1 8.3 272700 256888 ? Ss Jul10 72:49 /usr/bin/dbus-daemon --fork --print-pid 6 --print-address 9 --session

uptime : 00:35:59 up 27 days, 3:23, 3 users, load average: 0.36, 0.25, 0.40

As i run an archlinux, it's only a comment to help you find out. i'll post this to the dbus bugtracker

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-08-06 at 22:45 +0000, near wrote:

> As i run an archlinux, it's only a comment to help you find out. i'll
> post this to the dbus bugtracker
>
Again, please run massif over this to track where the memory is going.
It may simply be unreturned heap memory.

Scott
--
Scott James Remnant
<email address hidden>

[dark_construct (james-shredon)]

Greetings again friends,

I also still have this memory issue happening. However, I have been able to prevent it by avoiding certain programs. I have found that if I just run KDE (Kubuntu) and use Kate and Dolphin, then the memory increase does not happen. But if I use nautilus from KDE, it will. Also, if I log into gnome use Kate and Dolphin, i'll get the memory growth on dbus-daemon. It seems to stem from a gnome/kde mix. When the memory is increasing, I can Monitor the I/O through system monitor and see repeating ok's.

If I can help in some way, please let me know. Thanks for all of your time.

__James

[Steve Langasek (vorlon)]

I've reviewed the package in hardy-proposed and, since the effects of a configure flag are non-local and non-obvious, took a closer look at what this option changed.

As far as I'm able to tell, setting --disable-userdb-cache has *no* effect on the code in the hardy version of dbus; it sets a define in config.h which is then never used. Martin, can you confirm this, or else let me know what I've overlooked?

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-08-17 at 18:00 +0000, Steve Langasek wrote:

> As far as I'm able to tell, setting --disable-userdb-cache has *no*
> effect on the code in the hardy version of dbus; it sets a define in
> config.h which is then never used. Martin, can you confirm this, or
> else let me know what I've overlooked?
>
That sounds true to me - I remember having to *fix* the underlying
patches which got their #ifdef stuff horribly confused.

Scott
--
Scott James Remnant
<email address hidden>

[Martin Pitt (pitti)]

Indeed; sorry, should have checked more thoroughly when sponsoring, it looked like this was actually tested. Thanks for catching! I rejected the upload.

[Bruce Miller (brm0423)]

dbus-daemon appears to be the main cause of the unusable system performance I am experiencing on my Kubuntu Karmic setup:

bruce@Xenophon:~$ uname -a
Linux Xenophon 2.6.31-13-generic #44-Ubuntu SMP Sat Oct 10 15:27:14 UTC 2009 x86_64 GNU/Linux
bruce@Xenophon:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu karmic (development branch)
Release: 9.10
Codename: karmic
bruce@Xenophon:~$ ps aux | grep dbus-daemon
102 1029 0.0 0.0 24316 1424 ? Ss 01:02 1:09 dbus-daemon --system --fork
root 1755 0.0 0.0 23328 340 ? Ss 01:02 0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
bruce 2492 6.8 65.1 5889876 2642604 ? Ss 01:02 91:58 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
bruce 23700 0.0 0.0 7340 884 pts/3 R+ 23:22 0:00 grep dbus-daemon
bruce@Xenophon:~$

I am not the prime target of a development release because I am not a developer and, above all, I do not "do code." On the other hand, I have been beating the .... out of alpha and beta software for almost 30 years and have learned a thing or two about the subject over the time, including to follow developers' instructions on tracking down problems.

[Bruce Miller (brm0423)]

Further to above, I updated the kernel last night. The system has been up less than 24 hours. To the best of my recall, I have not logged out of and back into the current KDE session during that time.

bruce@Xenophon:~$ free
             total used free shared buffers cached
Mem: 4057860 4008208 49652 0 6152 208436
-/+ buffers/cache: 3793620 264240
Swap: 10442196 3879008 6563188

As the output of ps aux in my previous comment shows, dbus-daemon is taking 2.6 GB of RAM. A tmpfs filesystem of 832MB leaves little memory out of the 4 GB installed. It is not surprising that there is about 3.8GB of swap in use. My Osborne 1A ran faster than this in 1982, and it had a massive 64kB of RAM.

[Bruce Miller (brm0423)]

Further to above, I have killed amarok, and dbus-daemon memory consumption has declined slightly.

What has not yet declined is the number of zombie bash processes being reported by top. These also appear to be related to amarok Are they also connected to this dbus-daemon issue?

bruce@Xenophon:~$ ps aux | grep bash
bruce 4617 0.0 0.0 22060 3624 pts/1 Ss Oct11 0:00 /bin/bash
bruce 10150 1.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10156 2.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10159 3.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10177 2.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10188 1.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10203 2.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10207 2.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10211 2.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10215 1.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10221 2.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10224 2.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10228 1.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10233 2.0 0.0 0 0 ? Z 00:07 0:00 [bash] <defunct>
bruce 10238 1.0 0.0 0 0 ? Z 00...

[Bruce Miller (brm0423)]

Sorry to be swamping this thread with messages.

In an effort to isolate problems on my system, I have:
(1) temporarily removed amarok and its two helper packages
(2) restarted the system

top continues to report dozens of zombie bash instances. They are spawned fast and many (?) appear to be cleaned up fast. (I thought the whole point of a zombie process was that it couldn't be cleaned up, but that shows how little I know :-( ) These zombie processes appear to be linked to amarok, but amarok is not running on this system. It is uninstalled.

root@Xenophon:~# ps aux | grep bash
bruce 1780 0.0 0.0 10956 1712 pts/2 S+ 00:42 0:00 /bin/bash /home/bruce/bin/speedfox
bruce 2778 0.0 0.0 10956 896 pts/2 S+ 00:42 0:00 /bin/bash /home/bruce/bin/speedfox
bruce 5015 0.0 0.0 10428 1392 ? R 00:46 0:00 /bin/bash -c milTime=`qdbus org.kde.amarok /Player PositionGet`;totalTime=`qdbus org.kde.amarok /Player GetMetadata | grep mtime | cut -c 8-`;ttime=$( [ `expr length $((totalTime/1000 % 60))` -lt 2 ] && echo $((totalTime/60000)):0$((totalTime/1000 % 60)) || echo $((totalTime/60000)):$((totalTime/1000 %60)) );ctime=$( [ `expr length $((milTime/1000 % 60))` -lt 2 ] && echo $((milTime/60000)):0$((milTime/1000 % 60)) || echo $((milTime/60000)):$((milTime/1000 %60)) );echo $ctime / $ttime
bruce 5018 0.0 0.0 0 0 ? Z 00:46 0:00 [bash] <defunct>
bruce 5025 0.0 0.0 0 0 ? Z 00:46 0:00 [bash] <defunct>
bruce 5031 0.0 0.0 10420 1340 ? S 00:46 0:00 /bin/bash -c qdbus org.kde.amarok /Player GetMetadata | grep 'artist:' | sed -e 's/artist: //g'
root 5036 0.0 0.0 7336 868 pts/1 R+ 00:46 0:00 grep bash
bruce 6891 0.0 0.1 22060 4832 pts/1 Ss 00:34 0:00 /bin/bash
bruce 6892 0.0 0.1 22060 4828 pts/2 Ss 00:34 0:00 /bin/bash
root 23388 0.0 0.1 21540 4552 pts/1 S 00:38 0:00 /bin/bash
root@Xenophon:~# exit
exit
bruce@Xenophon:~$ pa | grep dbus-daemon
102 1235 0.1 0.0 23804 1444 ? Ss 00:33 0:01 dbus-daemon --system --fork
root 1894 0.0 0.0 23328 812 ? Ss 00:33 0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
bruce 3205 4.2 0.2 33176 10816 ? Rs 00:33 0:36 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
bruce 19506 0.0 0.0 7336 872 pts/1 R+ 00:48 0:00 grep dbus-daemon
bruce@Xenophon:~$ dpkg -l | grep amarok
rc amarok 2:2.2.0-0ubuntu2 easy to use media player based on the KDE 4 technology platform
bruce@Xenophon:~$ ps aux | grep amarok
bruce 17117 0.0 0.0 10428 1388 ? S 00:54 0:00 /bin/bash -c milTime=`qdbus org.kde.amarok /Player PositionGet`;totalTime=`qdbus org.kde.amarok /Player GetMetadata | grep mtime | cut -c 8-`;ttime=$( [ `expr length $((totalTime/1000 % 60))` -lt 2 ] && echo $((totalTime/60000)):0$((totalTime/1000 % 60)) || echo $((totalTime/60000)):$((totalTime/1000 %60)) );ctime=$( [ `expr length $((milTime/1000 % 60))` -lt 2 ] && echo $((milTime/60000)):0$((milTime/1000 % 60)) || echo $((milTi...

[Angus (eightmillion)]

Hi Bruce,

I'm the original filer of this bug report and also the writer of that little bit of code that bash is running (perhaps not coincidentally). It's part of a superkaramba theme I made a while back, so you might check to see if that's running. Also, if the bash processes aren't being properly cleaned up by superkaramba, you might consider filing a bug report against it.

[Bruce Miller (brm0423)]

It is 8.5 hours since I restarted the system and logged back into KDE.

Here is the output of ps -avx:
bruce@Xenophon:~$ ps avx | grep dbus-daemon
 1235 ? Ss 0:20 3 311 23596 1364 0.0 dbus-daemon --system --fork
 1894 ? Ss 0:00 0 311 23016 812 0.0 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
 3205 ? Ss 26:03 0 311 1045088 957716 23.6 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
32577 pts/1 R+ 0:00 0 103 7236 892 0.0 grep dbus-daemon

Here is the final screen of the fast-scrolling output of dbus-monitor:
method call sender=:1.504036 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method call sender=:1.504036 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "destination=':1.504036'"
method call sender=:1.504036 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.freedesktop.DBus"
method call sender=:1.504036 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged'"
method call sender=:1.504036 -> dest=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.kde.amarok"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=91 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.504036"
   string ":1.504036"
   string ""
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=92 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.504037"
   string ""
   string ":1.504037"
method call sender=:1.504037 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method call sender=:1.504037 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "destination=':1.504037'"
method call sender=:1.504037 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.freedesktop.DBus"
method call sender=:1.504037 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged'"
method call sender=:1.504037 -> dest=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.kde.amarok"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=93 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.504037"
   string ":1.504037"
   string ""
signal sender...

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-10-12 at 04:13 +0000, Bruce Miller wrote:

> What has not yet declined is the number of zombie bash processes being
> reported by top. These also appear to be related to amarok Are they also
> connected to this dbus-daemon issue?
>
Not sure, but they're definitely amarok's fault.

For the dbus-daemon issue, I really need you to run "massif" over it to
help isolate where the memory is going (see above)

Scott
--
Scott James Remnant
<email address hidden>

[Bruce Miller (brm0423)]

bruce@Xenophon:~$ valgrind --tool=massif /bin/dbus-daemon --system
==1225== Massif, a heap profiler
==1225== Copyright (C) 2003-2009, and GNU GPL'd, by Nicholas Nethercote
==1225== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==1225== Command: /bin/dbus-daemon --system
==1225==
Failed to start message bus: The pid file "/var/run/dbus/pid" exists, if the message bus is not running, remove this file
==1225==
bruce@Xenophon:~$

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-10-12 at 13:18 +0000, Bruce Miller wrote:

> bruce@Xenophon:~$ valgrind --tool=massif /bin/dbus-daemon --system
> ==1225== Massif, a heap profiler
> ==1225== Copyright (C) 2003-2009, and GNU GPL'd, by Nicholas Nethercote
> ==1225== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
> ==1225== Command: /bin/dbus-daemon --system
> ==1225==
> Failed to start message bus: The pid file "/var/run/dbus/pid" exists, if the message bus is not running, remove this file
> ==1225==
> bruce@Xenophon:~$
>
You'll obviously need to stop the running system bus daemon and start a
new one under massif (this will probably crash X)

Scott
--
Scott James Remnant
<email address hidden>

[Bruce Miller (brm0423)]

Here's the new massif.out

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-10-12 at 14:22 +0000, Bruce Miller wrote:

> Here's the new massif.out
>
> ** Attachment added: "massif.out.14298"
> http://launchpadlibrarian.net/33495789/massif.out.14298
>
I do not believe that this shows a memory leak, merely a usual increase
of heap size due to excessive repeated use. (ie. it's largely free()d
memory that malloc() cannot return to the operating system)

That shouldn't cause memory pressure issues since over-commit will
already take care of that.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-10-12 at 14:22 +0000, Bruce Miller wrote:

> Here's the new massif.out
>
> ** Attachment added: "massif.out.14298"
> http://launchpadlibrarian.net/33495789/massif.out.14298
>
OOI how long did you leave this running for? You might need to let it
accumulate more data so that the leak is "large" enough to see.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-10-15 at 07:11 -0700, Bruce Miller wrote:

> I am sorry that I missed your most recent messages in the thread on
> Bug 295741. I found them last night. I have stopped restarting kdm
> every few hours and will reply to the bug thread with the results.
>
Good to know, look forwards to seeing them.

> I am puzzled by your comment that you "do not believe that this shows
> a memory leak, merely a usual increase of heap size due to excessive
> repeated use". The excess does not arise from the problem between
> keyboard and chair; it is arising from something occurring within the
> installed software which is beyond [this] user's control. How can I
> help trace the source of the excess?
>
I didn't mean to imply user error either.

An artefact of the way that memory management in Linux works is that
applications have to request additional memory when they need it, but
that it is difficult to return that memory when they don't need it
anymore.

Here's a (hopefully layman summary why). Memory exists in a single map
called the heap, which the application splits up into the difference
uses.

[XXXXXXXXXX]

When it needs more, it extends the size of the heap:

[XXXXXXXXXX ]

And begins to allocate from that

[XXXXXXXXXXXXXXXX]

If it now frees a region of memory, it's relatively rare that it's the
most recently allocated thing (at the top of the heap)

[XX XXXXXXXXXX]

So it can't simply shrink the heap. It could try and defrag it, but
that's an insanely expensive and error-prone operation (especially if an
array crosses the divide).

Thus since it's rare that it's the top of the heap being freed, and hard
to defrag the heap, applications never bother. (They do try and re-use
the gaps though)

(When I say applications, I really mean the allocator in the common C
library.)

So long-term usage of a machine will show ever-increasing memory usage.
But that's ok, it's a game.

This isn't *real* memory, it's virtual memory.

Linux (in co-operation with the MMU on your processor) keeps track of
which pages you're *actually* using. This is why there are two numbers
in "ps":

 VSZ (Virtual Size) - how big it would be if it actually used all the
 memory claimed

 RSS (Resident Set Size) - how much memory it's actually using right now

For me, D-Bus might have a VSZ of 24MB, but it's RSS is under 2MB:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
102 928 0.0 0.0 24320 1916 ? Ss Oct14 0:05
dbus-daemon --system --fork

In fact, Linux pretty much ignores the virtual size, it doesn't even
need to be backed by virtual memory (so-called overcommit).

A nice fun game is to add up all the VSZ fields:

warcraft scott% ps aux | awk 'BEGIN { vsz = 0; } /[0-9]/ {vsz += $5;}
END { print vsz; }'
VSZ 12078188

ie. I'm apparently using 12 GB of virtual memory <g>

The massif output you gave looks like D-Bus has had so many requests
that it's had to increase its heap to deal with them. There's no real
evidence of a run-away leak there.

That might be just time-related though, in order to tell you need to let
it run for a while. In the case of a leak, you tend to see one
particular allocation consuming ...

[Bruce Miller (brm0423)]

Thank you for the layman's summary. It was a *_very helpful_* summary.

This KDE session loaded 28 hours ago. These are my current stats:
bruce@Xenophon:~$ ps aux | grep dbus-daemon
102 1201 0.0 0.0 27196 3620 ? Rs Oct14 2:13 dbus-daemon --system --fork
bruce 8802 2.9 24.6 1294240 1002004 ? Ss Oct15 51:13 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
bruce 9062 0.0 0.0 7340 884 pts/1 S+ 07:37 0:00 grep dbus-daemon
root 11149 0.0 0.0 23328 412 ? Ss Oct14 0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
bruce@Xenophon:~$ free
             total used free shared buffers cached
Mem: 4057808 3612772 445036 0 42420 1067412
-/+ buffers/cache: 2502940 1554868
Swap: 10442196 648436 9793760
bruce@Xenophon:~$

If I continue to wait, the dbus-daemon RSS memory allocation will continue to increase. The highest I have ever seen is ~2.6GB or about 66% of memory. By that point, the computer will be close to unusable.

At what point will it be useful for me to generate a massif.out report?

[Bruce Miller (brm0423)]

By the time that I went to generate a massif.out report, the KDE session was up to its neck in swap page quicksand and I forgot the instruction about killing dbus-daemon first. I eventually did look up the instructions, and the report is attached. But along the way, valgrind reported that it had had a malfunction requiring a bug submission.

Output attached.

[Scott James Remnant (Canonical) (canonical-scott)]

Interesting, it's your *session* bus that has the high memory consumption. That's a bit more tricky to debug, since it's started from within X.

In fact, I don't have any idea how to do that at the moment :-/

[Bruce Miller (brm0423)]

Your most recent post was discouraging: if the brightest minds of Canonical aren't immediately clear how to trace the single largest problem undermining my productive use of Kubuntu, how do I stand a chance? :-( But I now have a couple of hunches to offer. So far, these are only hunches, which means that I am not yet able to substantiate them with evidence.

My first suspected villain is Adobe Flash --- a popular but proprietary closed-source product. My second suspected villain is the browser (which could be any one or all of the three Firefox versions (3.0, 3.5, 3.6pre) or chromium-browser, as the Google Chrome browser is called in the .ppa development repo).

Testing the hunches has started with a clean Kubuntu installation from the karmic RC release yesterday. So far, I have installed neither Flash nor any of the suspect browsers (although I am downloading them and some other stuff as I write). This session has only been up ten hours, so it is very early to start drawing conclusions. But so far, the dbus-daemon is taking only 0.5% of available memory. After this long Firefox/Chrome/Flash --- with the foolishly large number of tabs that I often have open --- would normally already be well over 10% and heading fast for over 20%.

Tastes vary. For my taste, Konqueror is too much of a hair shirt to be enjoyable in daily use and although I was once a paying customer of Opera, its most recent releases have not been to my taste either. So I will install Firefox, Chrome and Flash. But I will not enable Flash in Chrome. (P.S.: The Flash version will not be from the repos, it will be Adobe's 64-bit beta direct from the Adobe web site, which I check at least once a month as part of an overall system maintenance checklist.) In addition to AdBlockPlus, I will ensure that Flashblock is installed in Firefox with the most restrictive settings available.

After that has been running a few days, I will report back the dbus-daemon usage, and generate a massif.out file, it it appears to be indicated.

Thank you for all your work on this issue.

[Bruce Miller (brm0423)]

I consider my hunch of yesterday morning to be now substantiated. The benefits of blocking Adobe Flash make a difference as drastic as night and day.

My current uptime is trivial: only 36 hours, but for the last several months, my KDE session would by now long since have become unusable on this system with a Core 2 Duo and 4GB of RAM. dbus-daemon's RSS memory usage is stable plus or minus a few hundred bytes at 0.1% of memory. Before it would have been at >25%. System load, reported by (h)top, was frequently over 25; now, it is always under 0.1%; often, it is 0.01%.

Flash is now installed on the system, but only on Firefox; Flashblock is also installed. I have also intentionally not stayed away obsessively from Flash: as a test, I even played one YouTube video which demonstrated the technique that the accompanying article explained. Every time that I have viewed a Flash object, I have been careful to close the page immediately.

I had not thought that Flash could make so drastic a difference to the overall health of one's computer and computer usage.

[Florian Rathgeber (florian-rathgeber)]

Sorry for bringing this up again, but I see quite similar symptoms on a current natty install with kernel 2.6.37-5 and dbus 1.4.0-0ubuntu1 on a DELL E6510 laptop (NVIDIA NVS 3100M). When I try to suspend on battery (which fails because 2 tasks "fail to freeze"), dbus starts acting mad and currently consumes 3.4 GiB of memory! I don't really know what could be the cause. A related symptom is the gnome indicator-applet peaking the CPU such that I have to kill the process.

Just wanted to throw that in, maybe someone has an idea or the devs want to take a look (I'm happy to provide and logs etc. that can help).

[Haikal Pribadi (haikalpribadi)]

yes it definitely still exists, i'm on maverick, and it has been occuring for the last 2 months. and really hard to produce.. could anybody help us here? feel free to ask me anything that i should provide, i would love to, i just don't know what to provide right now. and it's really hard to produce this bug again (for me).. it always peaks up randomly.

i saw a post (above) asking to provide the output from "ps avx", so i'll start off with it (although i honestly don't know what it is):

  PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
    1 ? Ss 0:02 21 113 23770 2016 0.0 /sbin/init
    2 ? S 0:00 0 0 0 0 0.0 [kthreadd]
    3 ? S 0:00 0 0 0 0 0.0 [ksoftirqd/0]
    4 ? S 0:00 0 0 0 0 0.0 [migration/0]
    5 ? S 0:00 0 0 0 0 0.0 [watchdog/0]
    6 ? S 0:00 0 0 0 0 0.0 [migration/1]
    7 ? S 0:00 0 0 0 0 0.0 [ksoftirqd/1]
    8 ? S 0:00 0 0 0 0 0.0 [watchdog/1]
    9 ? S 0:00 0 0 0 0 0.0 [migration/2]
   10 ? S 0:00 0 0 0 0 0.0 [ksoftirqd/2]
   11 ? S 0:00 0 0 0 0 0.0 [watchdog/2]
   12 ? S 0:00 0 0 0 0 0.0 [migration/3]
   13 ? S 0:01 0 0 0 0 0.0 [ksoftirqd/3]
   14 ? S 0:00 0 0 0 0 0.0 [watchdog/3]
   15 ? S 0:00 0 0 0 0 0.0 [migration/4]
   16 ? S 0:03 0 0 0 0 0.0 [ksoftirqd/4]
   17 ? S 0:00 0 0 0 0 0.0 [watchdog/4]
   18 ? S 0:01 0 0 0 0 0.0 [migration/5]
   19 ? S 0:04 0 0 0 0 0.0 [ksoftirqd/5]
   20 ? S 0:00 0 0 0 0 0.0 [watchdog/5]
   21 ? S 0:01 0 0 0 0 0.0 [migration/6]
   22 ? S 0:03 0 0 0 0 0.0 [ksoftirqd/6]
   23 ? S 0:00 0 0 0 0 0.0 [watchdog/6]
   24 ? S 0:01 0 0 0 0 0.0 [migration/7]
   25 ? S 0:03 0 0 0 0 0.0 [ksoftirqd/7]
   26 ? S 0:00 0 0 0 0 0.0 [watchdog/7]
   27 ? S 0:00 0 0 0 0 0.0 [events/0]
   28 ? S 0:00 0 0 0 0 0.0 [events/1]
   29 ? S 0:00 0 0 0 0 0.0 [events/2]
   30 ? S 0:00 0 0 0 0 0.0 [events/3]
   31 ? S 0:00 0 0 0 0 0.0 [events/4]
   32 ? S 0:00 0 0 0 0 0.0 [events/5]
   33 ? S 0:00 0 0 0 0 0.0 [events/6]
   34 ? S 0:00 0 0 0 0 0.0 [events/7]
   35 ? S 0:00 0 0 0 0 0.0 [cpuset]
   36 ? S 0:00 0 0 0 0 0.0 [khelper]
   37 ...

[Kakapapa (kakapapa)]

When I executed dbus-daemon with verbose mode(described in man page),
I could see strange thing after few minutes(output is grepped).
-----
6315: Message 0xb7ff7fe8 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 1 pending to send
6315: Message 0xb7ff7fe8 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 1 pending to send
6315: Message 0xb7ffc640 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 1 pending to send
6315: Message 0xb7ffb9e0 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 2 pending to send
6315: Message 0xb7ff9a58 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 3 pending to send
6315: Message 0xb7ffe938 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 4 pending to send
6315: Message 0xb7ff9f68 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 5 pending to send
6315: Message 0xb7ffca18 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 6 pending to send
6315: Message 0xb7ffc838 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 7 pending to send
6315: Message 0xb7ffe078 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 8 pending to send
6315: Message 0xb7ff7fe8 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 9 pending to send
6315: Message 0xb7fff7d8 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 10 pending to send
6315: Message 0xb7ffc9a0 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 11 pending to send
6315: Message 0xb7fffb88 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 12 pending to send
6315: Message 0xb7ffceb0 (4 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged 'sss') for null added to outgoing queue 0xb7fe7a78, 13 pending to send
...
-----

[Jamie Strandboge (jdstrand)]

Thank you for reporting this bug to Ubuntu. hardy has reached EOL
(End of Life) for this package and is no longer supported. As
a result, this bug against hardy is being marked "Won't Fix".
Please see https://wiki.ubuntu.com/Releases for currently
supported Ubuntu releases.

Please feel free to report any other bugs you may find.

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".