[Pkg-utopia-maintainers] Bug#903837: dbus: SDDM with theme Breeze and KDE programs (e.g. Dolphin) take +30 seconds to start

[Simon McVittie]

Control: tags -1 + moreinfo

On Sun, 15 Jul 2018 at 18:33:39 +0300, Alex Dănilă wrote:
> The following take very long to start, 30 seconds to 2 minutes:
> - SDDM with theme Breeze (doesn't happen with default Maui)
> - kscreenlocker_greet - the first to show the behaviour, since about 1 week
> - Amarok
> - Dolphin
> - Krunner - it appears, but when the first letter is typed it will freeze for a while; after the freeze ends it will run correctly for the rest of the session.

Please look in the system log (systemd Journal or /var/log/syslog) for
any messages that look relevant, in particular around the times that
you are launching these programs. You can censor information from these
logs as long as you make it obvious what's been censored (replace with
XXXX or similar).

Did this problem start with a recent upgrade of some package? The files
in /var/log/apt might be useful to remind you what has been upgraded
recently.

The default timeout for a D-Bus method call is 25 seconds, so if some
program blocks for 25 seconds and then proceeds, it is usually a sign
that it is waiting for a D-Bus method call to finish. This could be a
bug in the program that is blocking, the program that it is contacting,
or the dbus-daemon through which they communicate.

> Amarok:
> (gdb) where
...
> #5  0x00007fffe34777fe in dbus_connection_send_with_reply_and_block () at /lib/x86_64-linux-gnu/libdbus-1.so.3
> #6  0x00007ffff0f7ed93 in q_dbus_connection_send_with_reply_and_block (error=0x7fffffffd240, timeout_milliseconds=-1, message=0x55555594a630, connection=<optimized out>) at qdbus_symbols_p.h:135
> #7  0x00007ffff0f7ed93 in QDBusConnectionPrivate::sendWithReply(QDBusMessage const&, int, int) (this=this at entry=
>     0x555555ce4890, message=..., sendMode=sendMode at entry=1, timeout=timeout at entry=-1) at qdbusintegrator.cpp:1912
> #8  0x00007ffff0f80f53 in QDBusConnectionPrivate::findMetaObject(QString const&, QString const&, QString const&, QDBusError&) (this=0x555555ce4890, service=..., path=..., interface=..., error=...) at qdbusintegrator.cpp:2386
> #9  0x00007ffff0f8dd0b in QDBusInterfacePrivate::QDBusInterfacePrivate(QString const&, QString const&, QString const&, QDBusConnection const&) (this=0x555555d19200, serv=..., p=..., iface=..., con=...) at qdbusinterface.cpp:158
> #10 0x00007ffff0f8de65 in QDBusInterface::QDBusInterface(QString const&, QString const&, QString const&, QDBusConnection const&, QObject*) (this=0x555555d18c98, service=..., path=..., interface=..., connection=..., parent=0x0) at qdbusinterface.cpp:220
> #11 0x00007ffff18177c9 in Solid::Backends::UPower::UPowerManager::UPowerManager(QObject*) (this=0x555555d18c80, parent=<optimized out>)
>     at ./solid/solid/backends/upower/upowermanager.cpp:41
> #12 0x00007ffff17bc12b in Solid::ManagerBasePrivate::loadBackends() (this=this at entry=0x555555b887c0) at ./solid/solid/managerbase.cpp:99

It looks like the "Solid" hardware management library used by Amarok is
contacting UPower and waiting for a reply. It should probably be using
an asynchronous call that does not block the main loop, instead of a
blocking call. There might also be some problem with the Solid library
or with UPower.

> For Dolphin
> (gdb) where
...
> #14 0x00007ffff5baaebb in Solid::DeviceNotifier::instance() () from /usr/lib/x86_64-linux-gnu/libKF5Solid.so.5

This could well be something similar.

    smcv