My plasma-desktop is critically sluggish, panel and kdialog reacts after few minutes because of dbus Timeout problem

[kenorb]

I've been sent from pillar to post from almost few days, spent already few days investigating my Ubuntu slugginess right just after install, so I hope this report is now in the right place. I don't have time for this, I really need to work, instead of spending days fighting with simple usage of Ubuntu and reporting the bugs and receiving messages like 'this is not a bug of x', 'this is not a bug of y'.

The bug affects affect in general plasma-desktop on Ubuntu.

Some examples:
Using Chrome which uses KDialog, any file upload takes minutes.
KDialog timeouts after 25 seconds 4 times, makes it the whole minute to show up.

Steps to Reproduce:
1. Go to: https://code.google.com/p/chromium/issues/entry
2. Click on: Attach the file
3. Click on: Choose File
4. Problem: Nothing happens.
5. After 25 seconds KDialog appears.
6. It takes another 20-30 seconds to fully load (still you can't click anything).
7. After the whole 1 minute you can choose the file.

Other bugs which I've reported related to KDialog:

Against KDE KDialog:
https://bugs.kde.org/show_bug.cgi?id=307049
Status: "I can only guess from seeing the parts you posted, that there is a kded module blocking the D-Bus system. Please try disabling kded modules as described at http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/"

Against KDialog it-self:
https://bugs.launchpad.net/ubuntu/+source/kde-baseapps/+bug/1053869
Status: this is only a small issue of bigger thing

Other bugs which I've reported related to KDE plasma-desktop:

Steps to Reproduce:
1. Click on KDE "start" button
2. Nothing happens.
3. After 1 minute and 30 seconds you'll see the context menu!
Some people say, it's better later, than never.

Against KDE plasma-desktop:
https://bugs.kde.org/show_bug.cgi?id=307048
Status: currently ignored

And finally against the DBus it-self:
https://bugs.freedesktop.org/show_bug.cgi?id=55136
Status:
"This is probably the problem: there seems to be some sort of incompatibility
involving Ubuntu's "dbusmenu" system and how it interacts with Qt/KDE
applications. Please report this to the suppliers of the packages you're using
(Ubuntu, Kubuntu, or any third-party dbusmenu or KDE packages you're using).
I don't think this is a D-Bus bug."

Other related links:
http://<email address hidden>/msg00243.html

As well currently I can't do any launchpad upgrade or send any apport-collect, because of these annoying bugs:
https://answers.launchpad.net/ubuntu/+source/apt/+question/202373
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1053861
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1053400

So to not repeating my-self and pasting a bunch of strace, debug stuff (which you can access from the links above), the current status of this big Ubuntu and KDE bug as suggested from DBus support, is as follow:
> (process:7387): GLib-GIO-WARNING **: Received property menu with type s does not match expected type o in the expected interface void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such interface `com.canonical.dbusmenu' on object at path /"
Please report this to the suppliers of the packages you're using
(Ubuntu, Kubuntu, or any third-party dbusmenu or KDE packages you're using).

So now I'm reporting it now against Ubuntu, as my reports against KDE, X, DBus failed.

[kenorb (kenorb)]

When I'm using Chrome 18.0.1025.168 (Developer Build 134367 Linux) on Ubuntu 12.04, the KDialog takes around 25 seconds to show up!

Reproducible: Always

Steps to Reproduce:
1. Go to: https://code.google.com/p/chromium/issues/entry
2. Click on: Attach the file
3. Click on: Choose File
4. Problem: Nothing happens.
5. After 25 seconds KDialog appears.
6. It takes another 20-30 seconds to fully load (still you can't click anything).
7. After the whole 1 minute you can choose the file.

Expected Results:
In Firefox (which doesn't uses KDialog) it works within few seconds.

Qt: 4.8.1
KDE Development Platform: 4.8.4 (4.8.4)
KDialog: 1.0

When executed manually the following command:
strace kdialog --attach=71303405 --title=Open File --getopenfilename /home/kenorb/Sites/x/sites/all/modules/contrib/simpletest_clone

It seems to stop on poll for exactly 25 seconds!

write(3, "\1\0\0\0\0\0\0\0", 8) = 8
poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\225\24\31\0\32\0\300\5\1\0\0\0+\0\0\0\7\0\t\0\377\377\t\0\t\0\0\0\3648\0\0"..., 400}, {NULL, 0}, {"", 0}], 3) = 400
recvfrom(6, 0x7aef44, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\21\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\f\0\0\0org.kde.kded\0", 17}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 161
poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\t\0\0\0\6\0\0\0=\0\0\0\6\1s\0\6\0\0\0:1.162\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 89
recvmsg(7, 0x7fff4ef79770, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0"..., 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128
poll([{fd=7, events=POLLIN}], 1, 25000

Is there any sleep(25) or something? Why?
It happens every time to me when I'm trying to upload anything on any site in Chrome browser, but it also happens in other software using KDialog as well.

Qt: 4.8.1
KDE Development Platform: 4.8.5 (4.8.5)
KDialog: 1.0

[Christoph-maxiom (christoph-maxiom)]

Please temporarily rename ~/.kde/share/apps/kfileplaces/bookmarks.xml and try again. You might have some remote places in the places panel that get stuck waiting for a connection.

[kenorb (kenorb)]

I've moved the file. The file was re-created within few seconds after 'Choose file' click to default, but still it took KDialog 25 seconds to appear.
bookmarks.xml file seems to be default as it was.

[Christoph-maxiom (christoph-maxiom)]

Could you try running "solid-hardware list details" in a Konsole, and check if it blocks for the same long time? Is "dbus-daemon" running for your current user?

[kenorb (kenorb)]

Simulating the same command like as it was executed by Chrome (it's doing the same):
$ time kdialog --attach=56623340 --title="Open File" --getopenfilename /home/kenorb/Downloads/
kdialog(8234)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."

real 1m42.668s
user 0m0.496s
sys 0m0.088s
Time when kdialog was run and first attempt to click Cancel.

dbus-daemon is run for current user:

$ ps wuax | grep dbus-daemon
102 868 0.0 0.0 25064 2060 ? Ss 13:41 0:00 dbus-daemon --system --fork --activation=upstart
kenorb 1955 0.0 0.0 26476 2400 ? Ss 13:42 0:01 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
kenorb 8247 0.0 0.0 13580 932 pts/6 S+ 17:02 0:00 grep --color=auto dbus-daemon

[kenorb (kenorb)]

strace gives me this:

8549 sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\21\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\f\0\0\0org.kde.kded\0", 17}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 161 <0.000015>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}]) <0.000061>
8549 recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\t\0\0\0\6\0\0\0=\0\0\0\6\1s\0\6\0\0\0:1.169\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 89 <0.000009>
8549 recvmsg(7, 0x7fff71c561e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
8549 sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0"..., 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128 <0.000010>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.020763>

Last <number> show the time spent in system calls.
poll() = 25 seconds
I've 4 of these in one run:
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.020763>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.008094>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.025128>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.025123>
25 second each = 1 minute.
All are similar.

[kenorb (kenorb)]

Problem with KDialog I had before the upgrade of kde-plasma.
But after the upgrade, I've similar problem with kde-plasma panel. It takes half a minute to react on clicks, but it didn't happen before the upgrade.
So it could be something in common.

Link:
https://bugs.kde.org/show_bug.cgi?id=307048

[kenorb (kenorb)]

So the problem is related to DBus.
How do I diagnose while the dbus is run?

8758 recvmsg(7, 0x7fff53179c10, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000005>
8758 sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0\6\1s\0\f\0\0\0org.kde.kded\0\0\0\0\2\1s\0#\0\0\0org.freedesktop.DBus.Introspectable\0\0\0\0\0\3\1s\0\n\0\0\0Introspect\0\0\0\0\0\0", 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128 <0.000010>
8758 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.013023>

[Christoph-maxiom (christoph-maxiom)]

I can only guess from seeing the parts you posted, that there is a kded module blocking the D-Bus system. Please try disabling kded modules as described at http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/

Probable candidates are network manager related modules, or anything that is related to package updates.

[kenorb (kenorb)]

I've tried to restart dbus, but it didn't help.
While I wanted to kill it, it frozen my machine, so I had to reboot.

I don't know much about dbus, but I can see after clean reboot, something it's using debug resources much:
$ netstat -na | grep dbus | grep CONNECTED | wc -l
124

$ sudo netstat -nap | grep dbus | grep CONNECTED | awk '{print $8}' | sort | uniq -c
      2 1932/dbus-launch
     95 1933/dbus-daemon
      4 2490/gvfsd-trash
      2 2492/gvfsd-burn
     44 865/dbus-daemon

It's normal?

[kenorb (kenorb)]

Thanks for your help, I'll try to find some workaround for it.

[kenorb (kenorb)]

Basically I've huge problems with dbus.
My main problem is that different binaries like kdialog and plasma-desktop are freezing and crashing all the time, so I can't use my Linux (Ubuntu) desktop properly.

Problems include:
https://bugs.kde.org/show_bug.cgi?id=307049
https://bugs.kde.org/show_bug.cgi?id=307048

Here is strace example of sent message by kdialog:
8549 sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\21\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\f\0\0\0org.kde.kded\0", 17}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 161 <0.000015>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}]) <0.000061>
8549 recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\t\0\0\0\6\0\0\0=\0\0\0\6\1s\0\6\0\0\0:1.169\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 89 <0.000009>
8549 recvmsg(7, 0x7fff71c561e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
8549 sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0"..., 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128 <0.000010>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.020763>

Last <number> show the time spent in system calls.
poll() = 25 seconds
I've 4 of these in one run:
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.020763>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.008094>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.025128>
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.025123>
25 second each = 1 minute to run single popup window (kdialog).

The same happening with plasma-desktop, once I click on panel, it takes few minutes to react on my click!

Here are some socket statistics:
$ netstat -na | grep dbus | grep CONNECTED | wc -l
124

Is there any connection limit to dbus before the timeout?

$ sudo netstat -nap | grep dbus | grep CONNECTED | awk '{print $8}' | sort | uniq -c
      2 1932/dbus-launch
     95 1933/dbus-daemon
      4 2490/gvfsd-trash
      2 2492/gvfsd-burn
     44 865/dbus-daemon

I was playing with dbus-monitor, but it didn't help anything, because it doesn't show even which process (PID) is connecting to it. I found some references to (--print-pid), but I didn't know how to use this feature.

Here is something, that I found as possible cause of it.

When starting dbus-daemon manually, I've the following error:

$ /bin/dbus-daemon --print-pid 5 --print-address 7 --session
Failed to start message bus: Writing to pipe: Bad file descriptor

Running with sudo doesn't help either.

strace gives me this:

stat("/usr/share/dbus-1/services/org.gnome.Rhythmbox3.service", {st_mode=S_IFREG|0644, st_size=66, ...}) = 0
stat("/usr/share/dbus-1/services/org.ayatana.bamf.service", {st_mode=S_IFREG|0644, st_size=68, ...}) = 0
open("/usr/share/dbus-1/services/org.ayatana.bamf.service", O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=68, ...}) = 0
read(5, ""..., 68) = 68
close(5) = 0
stat("/usr/share/dbus-1/services/org.ayatana.bamf.service", {st_mode=S_IFREG|06...

[kenorb (kenorb)]

Related dbus bug:
https://bugs.freedesktop.org/show_bug.cgi?id=55136

[kenorb (kenorb)]

The other interesting thing I found, that actually KDialog sending the empty message!

As you can see before: msg_name(0)=NULL

[pid 15820] sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0\6\1s\0\f\0\0\0org.kde.kded\0\0\0\0\2\1s\0#\0\0\0org.freedesktop.DBus.Introspectable\0\0\0\0\0\3\1s\0\n\0\0\0Introspect\0\0\0\0\0\0", 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128

When I'm monitoring my dbus socket, it showed as:
$ dbus-monitor --address unix:path=/var/run/dbus/system_bus_socket --monitor

signal sender=org.freedesktop.DBus -> dest=(null destination) serial=31 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.71"
   string ""
   string ":1.71"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=32 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.71"
   string ":1.71"
   string ""

Destination is NULL.

This is other example how it suppose to look:
signal sender=org.freedesktop.DBus -> dest=:1.66 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.66"

Maybe that's the reason of timeout?

[kenorb (kenorb)]

[pid 15820] sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0\6\1s\0\f\0\0\0org.kde.kded\0\0\0\0\2\1s\0#\0\0\0org.freedesktop.DBus.Introspectable\0\0\0\0\0\3\1s\0\n\0\0\0Introspect\0\0\0\0\0\0", 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128

When I'm monitoring my dbus socket, it showed as:
$ dbus-monitor --address unix:path=/var/run/dbus/system_bus_socket --monitor

signal sender=org.freedesktop.DBus -> dest=(null destination) serial=31 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.71"
   string ""
   string ":1.71"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=32 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.71"
   string ":1.71"
   string ""

Destination is NULL, it's normal?

[Simon McVittie (smcv)]

(In reply to comment #0)
> Basically I've huge problems with dbus.
> My main problem is that different binaries like kdialog and plasma-desktop are
> freezing and crashing all the time, so I can't use my Linux (Ubuntu) desktop
> properly.

Please report this to your distribution (Ubuntu).

> When starting dbus-daemon manually, I've the following error:
>
> $ /bin/dbus-daemon --print-pid 5 --print-address 7 --session
> Failed to start message bus: Writing to pipe: Bad file descriptor

File descriptors 5 and 7 are not open, so that error message is to be expected.

Running the session dbus-daemon is part of X session startup; you can't (usefully) attach a new dbus-daemon to a running session.

> Running with sudo doesn't help either.

No, it won't.

(In reply to comment #0)
> Last <number> show the time spent in system calls.
> poll() = 25 seconds
> I've 4 of these in one run:
> 8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.020763>
> 8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.008094>
> 8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.025128>
> 8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.025123>

The default timeout for a D-Bus method call is 25 seconds, so this means your process (kdialog?) is sending a method call and not receiving a reply from the service it's communicating with. After 25 seconds, it gives up.

[Simon McVittie (smcv)]

(In reply to comment #0)
> Is there any connection limit to dbus

It's limited by the number of file descriptors it's allowed to open, usually 1024. A few file descriptors are used internally, so you can have about 1000 connections.

In 1.4.x, Bug #23194 you'll run into problems at half of that limit, so about 500.

[Simon McVittie (smcv)]

(In reply to comment #1)
> When I'm monitoring my dbus socket, it showed as:
> $ dbus-monitor --address unix:path=/var/run/dbus/system_bus_socket --monitor

When you are the only user logged in, there should usually be two dbus-daemon processes. One is the system bus (runs as user messagebus, listens on /var/run/dbus/system_bus_socket) and the other is the session bus (runs as your own user ID, listens on some address involving /tmp which you can get from the $DBUS_SESSION_BUS_ADDRESS environment variable). If you debug the wrong one, the results aren't likely to be very useful.

> Destination is NULL, it's normal?

Yes, broadcast signals have a null destination.

[Simon McVittie (smcv)]

From one of the KDE bugs you linked:

> (process:7387): GLib-GIO-WARNING **: Received property menu with type s does not match expected type o in the expected interface void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such interface `com.canonical.dbusmenu' on object at path /"

This is probably the problem: there seems to be some sort of incompatibility involving Ubuntu's "dbusmenu" system and how it interacts with Qt/KDE applications. Please report this to the suppliers of the packages you're using (Ubuntu, Kubuntu, or any third-party dbusmenu or KDE packages you're using).

I don't think this is a D-Bus bug.

[Christoph-maxiom (christoph-maxiom)]

Still looks like an issue with a kded module (see comment #8). Without trying which one you need to disable, it is nearly impossible to debug.

[Christoph-maxiom (christoph-maxiom)]

Note that KDialog itself does not use D-Bus itself; the problem is very likely in the solid libraries or runtime system. Which makes me wondering: Are you actually running a full KDE session, or do you use KDE software inside a different desktop?

[kenorb (kenorb)]

I'm using full KDE plasma desktop.

[kenorb (kenorb)]

Before I was using Unity, but it was even worse, it was freezing all the time, crashing, lots of missing options, just a nightmare. So KDE plasma is kind of relief for me, but it's still not perfect.

[kenorb (kenorb)]

Thanks for the detailed explanation and help.
I've reported another bug report here as follow-up:
https://bugs.freedesktop.org/show_bug.cgi?id=55136

[kenorb (kenorb)]

Sorry, wrong link.
This is the correct:
https://bugs.launchpad.net/ubuntu/+source/kde-baseapps/+bug/1053910

[kenorb (kenorb)]

Current follow-up:
https://bugs.launchpad.net/ubuntu/+source/kde-baseapps/+bug/1053910

[Christoph-maxiom (christoph-maxiom)]

So did you try disabling some kded modules? I know it is a tedious task, but I don't see any option right now. Filing more bug reports in different directions won't help if you do not follow the advices you get from there.

[kenorb (kenorb)]

> When you are the only user logged in, there should usually be two dbus-daemon
> processes. One is the system bus (runs as user messagebus, listens on
> /var/run/dbus/system_bus_socket) and the other is the session bus (runs as your
> own user ID, listens on some address involving /tmp which you can get from the
> $DBUS_SESSION_BUS_ADDRESS environment variable). If you debug the wrong one,
> the results aren't likely to be very useful.

Also if I could use a little of your specific knowledge about dbus to know more about my specific problem with dbus involved and what are the methods of debugging the source of this problem.

My other dbus instance is here:
$ echo $DBUS_SESSION_BUS_ADDRESS
unix:abstract=/tmp/dbus-4Lf6aHxvqg,guid=a5ec76744e9723954bcaa3f10000001e

Also I can see it in netstat:
$ netstat -nap --unix | grep LISTEN | grep dbus | head -n1
unix 2 [ ACC ] STREAM LISTENING 13380 1970/dbus-daemon @/tmp/dbus-4Lf6aHxvqg

But the problem is, that /tmp/dbus-4Lf6aHxvqg doesn't exist.

$ ll /tmp/dbus-4Lf6aHxvqg
ls: cannot access /tmp/dbus-4Lf6aHxvqg: No such file or directory

$ netstat -nap --unix | grep 4Lf6aHxvqg | wc -l
71
items are connected to this bus socket which doesn't exist.

This could be also the reason of that problem?

Also when debugging dbus-daemon, it gives me this:
recvmsg(17, {msg_name(0)=NULL, msg_iov(1)=[{"l\1\0\1\0\0\0\0\262\35\0\0\233\0\0\0\1\1o\0 \0\0\0/org/freedesktop/PowerManagement\0\0\0\0\0\0\0\0\6\1s\0\37\0\0\0org.freedesktop.PowerManagement\0\2\1s\0\37\0\0\0org.freedesktop.PowerManagement\0\3\1s\0\22\0\0\0GetPowerSaveStatus\0\0\0\0\0\0\0edesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.kde.ksmserver'\0\0\1\0\1\0\0\0\0\312\33\0\0t\0\0\0\1\1o\0\n\0\0\0/KSMServer\0\0\0\0\0\0\6\1s\0\21\0\0\0org.kde.ksmserver\0\0\0\0\0\0\0\2\1s\0\32\0\0\0org.kde.KSMServerInterface\0\0\0\0\0\0\3\1s\0\v\0\0\0canShutdown\0\0\0\0\0\0dMatch\0\0\0\0\0\0\0\0\10\1g\0\1s\0\0\215\0\0\0type='signal',sender='org.kde.StatusNotifierItem-2242-1',path='/StatusNotifierItem',interface='org.kde.StatusNotifierItem',member='NewStatus'\0\0rlayIcon'\0\0e='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.kde.ksmserver'\0\0reedesktop.DBus\0\0\0\0\3\1s\0\10\0\0\0AddMatch\0\0\0\0\0\0\0\0\10\1g\0\1s\0\0\255\0\0\0type='signal',sender='org.kde.networkmanagement',path='/org/kde/networkmanagement/Activatable/1',interface='org.kde.networkmanagement.Activatable',member='propertiesChanged'\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 176
recvmsg(17, 0x7fffde52f3e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLOUT}], 1, 0) = 0 (Timeout)
..
recvmsg(59, {msg_name(0)=NULL, msg_iov(1)=[{"l\4\1\1\0\0\0\0\271\5\0\0[\0\0\0\1\1o\0\23\0\0\0/StatusNotifierItem\0\0\0\0\0\2\1s\0\32\0\0\0org.kde.StatusNotifierItem\0\0\0\0\0\0\3\1s\0\n\0\0\0NewToolTip\0\0\0\0\0\0\0\1g\0\1s\0\0\6\0\0\0Active\0\0\0\0\0\0\10\1g\0\2su\0!\0\0\0org.kde.StatusNotifierItem-2450-"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 112
recvmsg(59, 0x7fffde52f3e0, MSG_CMSG_CLOEXEC) = -...

[Simon McVittie (smcv)]

(In reply to comment #8)
> My other dbus instance is here:
> $ echo $DBUS_SESSION_BUS_ADDRESS
> unix:abstract=/tmp/dbus-4Lf6aHxvqg,guid=a5ec76744e9723954bcaa3f10000001e
>
> Also I can see it in netstat:
> $ netstat -nap --unix | grep LISTEN | grep dbus | head -n1
> unix 2 [ ACC ] STREAM LISTENING 13380 1970/dbus-daemon
> @/tmp/dbus-4Lf6aHxvqg
>
> But the problem is, that /tmp/dbus-4Lf6aHxvqg doesn't exist.

It's an "abstract Unix socket" which doesn't exist in the filesystem, which means that when dbus-daemon exits, it doesn't need to delete a Unix socket special file like it would when using normal Unix sockets. Its address is actually "\0/tmp/dbus-4Lf6aHxvqg" where \0 represents a NUL byte (that's also what the @ in netstat represents).

This is normal, on OSs that have abstract Unix sockets (Linux and possibly Solaris, but not *BSD).

> recvmsg(59, 0x7fffde52f3e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily
> unavailable)

It is normal for an idle dbus-daemon to encounter EAGAIN. That just means "there are no more messages for you to read right now, try again later".

> Or maybe there is some better and cleaner way of diagnosing the problem.

dbus-monitor(1) and d-feet (a GUI application) might be helpful.

> Also how do I use --print-pid option in practical way to print actual PID of
> processes which are connecting to dbus?

That's not what that option does. It's nothing to do with the process IDs of D-Bus clients:

> kenorb 1970 0.0 0.1 30000 5856 ? Ss Sep19 0:07
> //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

Early in its startup, that process will have printed its own pid (1970 in this case) to file descriptor 5, and its address to file descriptor 7. Those file descriptors were pipes to dbus-launch, which was its parent process: it's how dbus-launch finds out what values to put in your GUI session's $DBUS_SESSION_BUS_ADDRESS and $DBUS_SESSION_BUS_PID. Once the session is up and running, those options have no further effect.

[kenorb (kenorb)]

I've installed d-feet and it gives me some interesting results, like (each of them repeating plenty of times):

$ d-fee
ERROR: Some clever service is trying to be cute and has the same signal name in the same interface
ERROR: Some clever service is trying to be cute and has the same method name in the same interface

ERROR:dbus.proxies:Introspect error on :1.117:/: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

ERROR:dbus.proxies:Introspect error on org.freedesktop.Notifications:/App: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ERROR:dbus.proxies:Introspect error on org.kde.DeviceNotifications:/DataEngine: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ERROR:dbus.proxies:Introspect error on org.freedesktop.Notifications:/KBookmarkManager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ERROR:dbus.proxies:Introspect error on org.kde.DeviceNotifications:/KIO: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ERROR:dbus.proxies:Introspect error on org.kde.StatusNotifierHost-2186:/MainApplication: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ERROR:dbus.proxies:Introspect error on org.kde.plasma-desktop:/kickoff: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ERROR:dbus.proxies:Introspect error on :1.129:/: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownObject: No such object path '/'
org.freedesktop...

[kenorb (kenorb)]

Thanks, I'm trying it now.
Because the panel doesn't work, I've to go to Settings from the command line:
$ systemsettings

As advised:
"Disable kded4 modules in System Settings > Startup and Shutdown > Service Manager."
I'm going to Startup and Shutdown, everything is fine till that moment.
When clicking on 'Service Manager', the window is freezing for around 1 minute and then I've the error:
"Unable to contact KDED."
Then all the Startup Services are gray/disabled and 'Not running'. So I can't change anything.

So I'm disabling all the services manually by renaming all files to something else:
$ cd /usr/share/kde4/services/kded
$ sudo rename 's/.desktop/.desktop.disabled/' *.desktop
$ kbuildsycoca4

[kenorb (kenorb)]

And finally:
$ killall -HUP kdeinit4
then my whole session was killed, killing all my processes, but after testing with disabled all kde modules it works, kdialog appears in less than 1 second (including loading) for 'Choose File' web widgets and KDE desktop-plasma panel is clickable again.
I'll do some more tests and I'll find the broken module. Thanks again.

[kenorb (kenorb)]

E.g.:
Enabling all modules starting with letter 'k':
$ sudo rename 's/.disabled//' k*.desktop.disabled
$ killall -HUP kdeinit4

[kenorb (kenorb)]

I can confirm, that this is caused by muon-notifier service.
After renaming /usr/share/kde4/services/kded/muon-notifier.desktop file and restarting kdeinit4 everything works fine and above two bugs are not reproducible.

$ dpkg -l | grep muon-notifier
ii muon-notifier 1.3.1-0ubuntu2 update notifier for KDE

[kenorb (kenorb)]

It looks line muon-notifier is the one which breaks kdialog functionality and plasma-desktop panel.
File: muon-notifier.desktop
Whatever it's.

Renaming /usr/share/kde4/services/kded/muon-notifier.desktop
and restarting kdeinit4 solve the problem.

$ dpkg -l | grep muon-notifier
ii muon-notifier 1.3.1-0ubuntu2 update notifier for KDE

[kenorb (kenorb)]

I'm confused also what's the policy and where I should report the bug of kde muon-notifier.
Here at bugs.kde.org directly, or at bugs.launchpad.net/ubuntu/+source/muon.
Also by creating a new bug, or following the current one.
As I understand, the policy on launchpad.net is that I should create always the new bugs.

[kenorb (kenorb)]

Enabling muon-notifier.desktop service creating following process:
kenorb 11328 0.0 0.3 131788 12392 ? S 13:55 0:00 /usr/bin/python /usr/share/kde4/apps/muon-notifier/releasechecker

When killing the process manually, it seems that everything is back to normal.

When running it manually again using the same command line, I've this error:

 /usr/bin/python /usr/share/kde4/apps/muon-notifier/releasechecker
Unhandled exception in thread started by <bound method MetaReleaseCore.download of <UpdateManager.Core.MetaRelease.MetaReleaseCore object at 0x228f9d0>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262, in download
    uri=urllib2.urlopen(req, timeout=20)
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
...
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer

Probably, because I'm behind the proxy.

[kenorb (kenorb)]

Killing the following process solve the problem:
kenorb 11328 0.0 0.3 131788 12392 ? S 13:55 0:00 /usr/bin/python /usr/share/kde4/apps/muon-notifier/releasechecker

[kenorb (kenorb)]

Thanks for the help.
I found the broken kde module: muon-notifier
After killing this process, my desktop started to breath.

[kenorb (kenorb)]

When running it manually again using the same command line, I've this error:

 /usr/bin/python /usr/share/kde4/apps/muon-notifier/releasechecker
Unhandled exception in thread started by <bound method MetaReleaseCore.download of <UpdateManager.Core.MetaRelease.MetaReleaseCore object at 0x228f9d0>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262, in download
    uri=urllib2.urlopen(req, timeout=20)
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
...
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer

Probably, because I'm behind the proxy.

[Jonathan Thomas (echidnaman)]

Git commit c67667633ada69b6feee0216de4da03de963a82c by Jonathan Thomas.
Committed on 26/09/2012 at 01:33.
Pushed by jmthomas into branch '1.4'.

Catch all exceptions coming from MetaReleaseChecker and don't let them hang the process.

*Grumble I hate python Grumble*
FIXED-IN:1.4.1

M +14 -10 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/c67667633ada69b6feee0216de4da03de963a82c

[Jonathan Thomas (echidnaman)]

Git commit ae8bcd2062e0285d204f53fbca3de0a024c3648b by Jonathan Thomas.
Committed on 26/09/2012 at 01:33.
Pushed by jmthomas into branch 'master'.

Catch all exceptions coming from MetaReleaseChecker and don't let them hang the process.

*Grumble I hate python Grumble*
FIXED-IN:1.4.1

M +14 -10 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/ae8bcd2062e0285d204f53fbca3de0a024c3648b

[Jonathan Thomas (echidnaman)]

Git commit abeacf1a952813f716b079d40189f1980692ebfc by Jonathan Thomas.
Committed on 26/09/2012 at 01:33.
Pushed by jmthomas into branch 'qapt2'.

Catch all exceptions coming from MetaReleaseChecker and don't let them hang the process.

*Grumble I hate python Grumble*
FIXED-IN:1.4.1

M +14 -10 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/abeacf1a952813f716b079d40189f1980692ebfc

[Jonathan Thomas (echidnaman)]

I've committed a fix upstream for 1.4.1: http://commits.kde.org/muon/c67667633ada69b6feee0216de4da03de963a82c

[kenorb (kenorb)]

I've updated this script, but it seems it still failing when running it:

$ python -d /usr/share/kde4/apps/muon-notifier/releasechecker
Unhandled exception in thread started by <bound method MetaReleaseCore.download of <UpdateManager.Core.MetaRelease.MetaReleaseCore object at 0xd1e750>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262, in download
    uri=urllib2.urlopen(req, timeout=20)
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1207, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1180, in do_open
    r = h.getresponse(buffering=True)
  File "/usr/lib/python2.7/httplib.py", line 1030, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline()
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer

Even there is try/except

[Jonathan Thomas (echidnaman)]

Could you try replacing "except Exception, e:" with "except BaseException, e:"? Apparently python's Exception class is only for non language-defined exceptions. :/ (Unlike Java exceptions... Another reason to hate python)

[kenorb (kenorb)]

I've tried, but it doesn't change anything.
Maybe because it's a separate thread?

Problem is happening in File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262
So the exception was caught by /usr/lib/python2.7/socket.py
socket.error: [Errno 104] Connection reset by peer

python -m trace -c -t /usr/share/kde4/apps/muon-notifier/releasechecker
MetaRelease.py(160): try:
MetaRelease.py(161): if os.path.getsize(self.METARELEASE_FILE) == 0:
 --- modulename: genericpath, funcname: getsize
genericpath.py(49): return os.stat(filename).st_size
MetaRelease.py(165): return True
MetaRelease.py(137): thread.start_new_thread(self.download, ())
releasechecker(35): while metaRelease.downloading:
releasechecker(36): time.sleep(1)
Unhandled exception in thread started by <bound method MetaReleaseCore.download of <UpdateManager.Core.MetaRelease.MetaReleaseCore object at 0x1a44fd0>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262, in download
    uri=urllib2.urlopen(req, timeout=20)
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1207, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1180, in do_open
    r = h.getresponse(buffering=True)
  File "/usr/lib/python2.7/httplib.py", line 1030, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline()
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer
releasechecker(35): while metaRelease.downloading:
releasechecker(36): time.sleep(1)
releasechecker(35): while metaRelease.downloading:
releasechecker(36): time.sleep(1)
releasechecker(35): while metaRelease.downloading:
releasechecker(36): time.sleep(1)

So basically script is ignoring 'Unhandled exception' and script is continuing to check the release every second.

Something similar which I found:
http://askubuntu.com/questions/130267/cant-update-to-ubuntu-12-04-on-11-10

[Jonathan Thomas (echidnaman)]

Git commit 6d9581b2984c89e0ed91a27a205b345e67198c01 by Jonathan Thomas.
Committed on 26/09/2012 at 18:01.
Pushed by jmthomas into branch '1.4'.

Exceptions that MetaReleaseCore throw during a download happen in a separate thread, so we can't catch them.

The root cause of the IOError seems to be the existence of a proxy, and it appears that UpdateManager has a proxy init function. (Poor design on UpdateManager's part...)
This should fix the root cause of this bug, but I fear for other exceptions that could be thrown that MetaReleaseCore won't catch for us...
I'll commit a separate fix to make our KProcess call to releasechecker non-blocking.

M +11 -14 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/6d9581b2984c89e0ed91a27a205b345e67198c01

[Jonathan Thomas (echidnaman)]

Git commit f4821f9050ccd4e56fde5cd2f13530bf5468f4c1 by Jonathan Thomas.
Committed on 26/09/2012 at 18:01.
Pushed by jmthomas into branch 'master'.

Exceptions that MetaReleaseCore throw during a download happen in a separate thread, so we can't catch them.

The root cause of the IOError seems to be the existence of a proxy, and it appears that UpdateManager has a proxy init function. (Poor design on UpdateManager's part...)
This should fix the root cause of this bug, but I fear for other exceptions that could be thrown that MetaReleaseCore won't catch for us...
I'll commit a separate fix to make our KProcess call to releasechecker non-blocking.

M +11 -14 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/f4821f9050ccd4e56fde5cd2f13530bf5468f4c1

[Jonathan Thomas (echidnaman)]

Git commit 4028651c70dc854965c2c994074f0798690b516d by Jonathan Thomas.
Committed on 26/09/2012 at 18:01.
Pushed by jmthomas into branch 'qapt2'.

Exceptions that MetaReleaseCore throw during a download happen in a separate thread, so we can't catch them.

The root cause of the IOError seems to be the existence of a proxy, and it appears that UpdateManager has a proxy init function. (Poor design on UpdateManager's part...)
This should fix the root cause of this bug, but I fear for other exceptions that could be thrown that MetaReleaseCore won't catch for us...
I'll commit a separate fix to make our KProcess call to releasechecker non-blocking.

M +11 -14 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/4028651c70dc854965c2c994074f0798690b516d

[Jonathan Thomas (echidnaman)]

(Sorry about the duplication of the mail, I pushed the commit to three branches and the commit hook picked up on all three)

Anyways, this should fix the "IOError due to proxy" issue. To really "fix" this I'll make the invocation of releasechecker asynchronous, so that shoddy programming on UpdateManager's part doesn't block kded until UpdateManager times out.

[Jonathan Thomas (echidnaman)]

Git commit 058d412f365744ce0a3b4c513385486390ca4ea5 by Jonathan Thomas.
Committed on 26/09/2012 at 18:45.
Pushed by jmthomas into branch '1.4'.

Asynchronize the process to check for a new release.
If UpdateManager hangs due to a bug/poor design on their part, we can be stuck for up to 25 seconds, hanging all of KDED along with us.

M +21 -5 kded/MuonNotifier.cpp
M +5 -2 kded/MuonNotifier.h
M +0 -24 kded/distupgradeevent/distupgradeevent.cpp
M +0 -3 kded/distupgradeevent/distupgradeevent.h
M +1 -0 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/058d412f365744ce0a3b4c513385486390ca4ea5

[Jonathan Thomas (echidnaman)]

Git commit 90bd4c2d893c76bcae539e33283cb1a10b2661ec by Jonathan Thomas.
Committed on 26/09/2012 at 18:45.
Pushed by jmthomas into branch 'master'.

Asynchronize the process to check for a new release.
If UpdateManager hangs due to a bug/poor design on their part, we can be stuck for up to 25 seconds, hanging all of KDED along with us.

M +21 -5 kded/MuonNotifier.cpp
M +5 -2 kded/MuonNotifier.h
M +0 -24 kded/distupgradeevent/distupgradeevent.cpp
M +0 -3 kded/distupgradeevent/distupgradeevent.h
M +1 -0 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/90bd4c2d893c76bcae539e33283cb1a10b2661ec

[Jonathan Thomas (echidnaman)]

Git commit 5029d161876711807f02943686d2383c01861c35 by Jonathan Thomas.
Committed on 26/09/2012 at 18:45.
Pushed by jmthomas into branch 'qapt2'.

Asynchronize the process to check for a new release.
If UpdateManager hangs due to a bug/poor design on their part, we can be stuck for up to 25 seconds, hanging all of KDED along with us.

M +21 -5 kded/MuonNotifier.cpp
M +5 -2 kded/MuonNotifier.h
M +0 -24 kded/distupgradeevent/distupgradeevent.cpp
M +0 -3 kded/distupgradeevent/distupgradeevent.h
M +1 -0 kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/5029d161876711807f02943686d2383c01861c35

[Launchpad Janitor (janitor)]

This bug was fixed in the package muon - 1.4.1-0ubuntu1

---------------
muon (1.4.1-0ubuntu1) quantal; urgency=low

  * New upstream bugfix release (LP: #1053910)
 -- Jonathan Thomas <email address hidden> Sat, 29 Sep 2012 15:08:07 -0400