[Bug 1053910] Re: My plasma-desktop is critically sluggish, panel and kdialog reacts after few minutes because of dbus Timeout problem
Bug Watch Updater
1053910 at bugs.launchpad.net
Thu Oct 4 07:43:48 UTC 2012
Launchpad has imported 11 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=55136.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2012-09-20T10:14:32+00:00 kenorb wrote:
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|0644, st_size=68, ...}) = 0
stat("/usr/share/dbus-1/services/org.gnome.evince.Daemon.service", {st_mode=S_IFREG|0644, st_size=74, ...}) = 0
open("/usr/share/dbus-1/services/org.gnome.evince.Daemon.service", O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=74, ...}) = 0
read(5, ""..., 74) = 74
close(5) = 0
stat("/usr/share/dbus-1/services/org.gnome.evince.Daemon.service", {st_mode=S_IFREG|0644, st_size=74, ...}) = 0
getdents(4, /* 0 entries */, 32768) = 0
close(4) = 0
write(7, ""..., 73) = -1 EBADF (Bad file descriptor)
close(3) = 0
write(2, ""..., 67Failed to start message bus: Writing to pipe: Bad file descriptor
) = 67
exit_group(1) = ?
First I thought it's failing because of the last file, but the file is fine and after moving it, it's still failing, so it must something else.
Currently it's up-and-running as:
102 872 0.0 0.0 25028 1884 ? Ss Sep19 0:00 dbus-daemon --system --fork --activation=upstart
kenorb 1969 0.0 0.0 26548 388 ? S Sep19 0:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
kenorb 1970 0.0 0.0 27792 3580 ? Ss Sep19 0:02 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
Any reboot or dbus service restart doesn't help.
After reboot, I've only first 10 seconds after KDE startup when it does actually work.
It's a bug? And how do I fix it? Or how to diagnose it?
How do I make my dbus running properly?
Any suggestions?
Thanks.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/0
------------------------------------------------------------------------
On 2012-09-20T11:57:28+00:00 kenorb wrote:
[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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/1
------------------------------------------------------------------------
On 2012-09-20T15:29:02+00:00 Simon McVittie wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/2
------------------------------------------------------------------------
On 2012-09-20T15:32:34+00:00 Simon McVittie wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/3
------------------------------------------------------------------------
On 2012-09-20T15:35:30+00:00 Simon McVittie wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/4
------------------------------------------------------------------------
On 2012-09-20T15:42:13+00:00 Simon McVittie wrote:
>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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/5
------------------------------------------------------------------------
On 2012-09-21T09:47:02+00:00 kenorb wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/7
------------------------------------------------------------------------
On 2012-09-21T09:47:33+00:00 kenorb wrote:
Sorry, wrong link.
This is the correct:
https://bugs.launchpad.net/ubuntu/+source/kde-baseapps/+bug/1053910
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/8
------------------------------------------------------------------------
On 2012-09-21T12:07:14+00:00 kenorb wrote:
> 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) = -1 EAGAIN (Resource temporarily unavailable)
Or maybe there is some better and cleaner way of diagnosing the problem.
Also how do I use --print-pid option in practical way to print actual PID of processes which are connecting to dbus?
I've the following dbus process, how do I restart it without killing my machine to see standard output.
kenorb 1970 0.0 0.1 30000 5856 ? Ss Sep19 0:07 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
When I restart it, my connection is lost, when I kill it, my system is crashing, so I'm not sure how do restart it to see what's on standard output (as it says in manual - 'Print the process ID of the message bus to standard output').
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/9
------------------------------------------------------------------------
On 2012-09-21T13:48:00+00:00 Simon McVittie wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/10
------------------------------------------------------------------------
On 2012-09-24T12:34:24+00:00 kenorb wrote:
Thanks for the help.
I found the broken kde module: muon-notifier
After killing this process, my desktop started to breath.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1053910/comments/14
** Changed in: dbus
Status: Unknown => Won't Fix
** Changed in: dbus
Importance: Unknown => High
** Bug watch added: KDE Bug Tracking System #307048
https://bugs.kde.org/show_bug.cgi?id=307048
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to muon in Ubuntu.
https://bugs.launchpad.net/bugs/1053910
Title:
My plasma-desktop is critically sluggish, panel and kdialog reacts
after few minutes because of dbus Timeout problem
To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1053910/+subscriptions
More information about the kubuntu-bugs
mailing list