Ubuntu
plasma-nm package

[sru] plasma-nm blocks temporarily on startup w/o bluetooth device – KDE/Plasma very slow to launch (Kubuntu 15.10)

Bug #1509334 reported by vmagnin
200
This bug affects 42 people
Affects Status Importance Assigned to Milestone
plasma-nm
Fix Released
Medium
plasma-nm (Ubuntu)
Fix Released
Undecided
Philip Muškovac
Wily
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
Plasma NM does synchronous DBus calls do bluez for the bluetooth status, which in some situations can take up to 30s to finish/reach a timeout.
As Plasma itself waits for Plasma NM to initialize, this can cause the Plasma login to take half a minute without any response.

[Test Case]
First of all, you need a system that is affected by this.
- Try to log in an see that it takes unusually long to do so (~30s)
- Enable wily-proposed and update plasma-nm
- Reboot and verify that the login now takes 5-10s

[Regression potential]
This is mostly just reworking existing BT activation code, so the worst that should happen is the adapter getting enabled a while after the Desktop finished loading. As that's a normal use case when you enable an adapter by hand later on this shouldn't cause any issues.

[Original Description]
On my four PCs upgraded from Kubuntu 15.04 to 15.10, I have the same problem: for two days, KDE/Plasma is very long to launch. The desktop begins to appear but I must wait nearly one minute for all plasma widgets and icons to appear. And I repeat, this is happening on 4 different machines !

Once everything is finally launched, the system seems OK.

Update: removing the network manager app from the taskbar solves the problem.

See original description
Revision history for this message
In , quess (quess) wrote :

Hello

i just upgraded an Kubuntu 15.04 to 15.10 today.
After ssdm login, plasma starts launching, I can see wallpaper and desktop icons, but taskbar is empty. Nothing can be done during 30 first seconds with mouse or keyboard in this tty.
During this time, in another tty1 I can see cpu at 3% only...

I reproduce the problem at every startup and at every login with my usual login or with a newly created account.

Bootchart shows a python3 process sleeping a long time and then plasmashell finishes to load..
How to identify this process or to debug it?

Reproducible: Always

I can attach bootchart.svg if necessary

Revision history for this message
In , U26 (u26) wrote :

I can attach bootchart.svg if necessary

yes please.

Revision history for this message
In , U26 (u26) wrote :

Marking as needsinfo till we get the chart, as till then this doesn't contain anything to go on

Revision history for this message
oleoleole (ole-gidderikke) wrote :

I have the same problem, and I tried to create a new user. Even "Try Kubuntu Desktop" from the install disc does the same. It's very annoying and I'm trying to figure out what it is.

Revision history for this message
vmagnin (vincent-magnin) wrote :

The problem appeared after the following upgrade :

Start-Date: 2015-10-21 21:51:23
Commandline: apt-get dist-upgrade
Upgrade: vim-tiny:i386 (7.4.712-2ubuntu3, 7.4.712-2ubuntu4), vim-runtime:i386 (7.4.712-2ubuntu3, 7.4.712-2ubuntu4), gir1.2-udisks-2.0:i386 (2.1.6-2, 2.1.6-2ubuntu1), plasma-pa:i386 (5.4.2-0ubuntu2, 5.4.2-0ubuntu3), lintian:i386 (2.5.36.1ubuntu1, 2.5.36.1ubuntu2), libkf5wallet5:i386 (5.15.0-0ubuntu1, 5.15.0-0ubuntu2), ubuntu-release-upgrader-qt:i386 (15.10.10, 15.10.13), ubuntu-release-upgrader-gtk:i386 (15.10.10, 15.10.13), usb-creator-kde:i386 (0.2.67ubuntu0.1, 0.2.67ubuntu1), libkwalletbackend5-5:i386 (5.15.0-0ubuntu1, 5.15.0-0ubuntu2), ubuntu-release-upgrader-core:i386 (15.10.10, 15.10.13), vim-gui-common:i386 (7.4.712-2ubuntu3, 7.4.712-2ubuntu4), udisks2:i386 (2.1.6-2, 2.1.6-2ubuntu1), vim-common:i386 (7.4.712-2ubuntu3, 7.4.712-2ubuntu4), vim:i386 (7.4.712-2ubuntu3, 7.4.712-2ubuntu4), vim-gnome:i386 (7.4.712-2ubuntu3, 7.4.712-2ubuntu4), libkf5wallet-bin:i386 (5.15.0-0ubuntu1, 5.15.0-0ubuntu2), libudisks2-0:i386 (2.1.6-2, 2.1.6-2ubuntu1), usb-creator-common:i386 (0.2.67ubuntu0.1, 0.2.67ubuntu1), python3-distupgrade:i386 (15.10.10, 15.10.13), libkf5wallet-data:i386 (5.15.0-0ubuntu1, 5.15.0-0ubuntu2)
End-Date: 2015-10-21 21:51:39

(extracted from /var/log/apt/history.log)

These upgrades solved the kwalletd Bug #1504626, but added the present bug...

Revision history for this message
In , quess (quess) wrote :

Created attachment 95094
bootchart svg

python3 from 10th to 60th second on boot

Revision history for this message
rmannstaedt (ruben-visualtech) wrote :

Same problem, immediately after upgrading from Kubuntu 15.04 to Kubuntu 15.10, yesterday.
Problem is persistent and exists every time I logon.
Have tried (no effect, problem persists):
 - deleting panel and creating a new (default) panel instead.
 - deleting ~/.kde
 - sudo apt-get remove telepathy-*

This is _extremely_ annoying and I am contemplating either reinstalling 15.10 or simply going back to 15.04 ...

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in kde-runtime (Ubuntu):
status: New → Confirmed
Revision history for this message
vmagnin (vincent-magnin) wrote :

Waiting for the fix, my workaround is to automatically launch the Yakuake terminal at startup: by pressing F12 I can access to yakuake and work in command line, waiting for plasma to be ready. You can then launch firefox or libreoffice by command line, for example.

Revision history for this message
irisindigo (irisoxygen2) wrote :

I confirm this bug. It happens to me too.

Revision history for this message
altadeos (altadeos) wrote :

Hello,

Same problem here.

Regards.

Revision history for this message
In , U26 (u26) wrote :

thanks

Revision history for this message
In , U26 (u26) wrote :

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

Revision history for this message
In , U26 (u26) wrote :

No idea what that python process is.

It's not anything from Plasma.

Can you try and find out?

also a time this long with no CPU activity is probably DBus blocking - we'll be waiting for a reply from something that isn't answering.

Any chance you can add
"dbus-monitor > ~/my-dbus-log" to your startkde file

Revision history for this message
In , amichair (amichai2) wrote :

Same problem here. Just upgraded today, panel takes a minute to be operational. Beore that it's kind of half-drawn, with some task buttons there, some icon frames, and many icons just missing. After a long while it all just works. This happens after reboot, but also saw it at other times (possibly after monitor resumes from power savings mode? not sure). At the moment I have a completely frozen panel, not sure if it's related or not.

Revision history for this message
In , amichair (amichai2) wrote :

btw I just found out that it happens consistently every time I 'killall plasmashell && plasmashell'. No need to reboot to recreate.

Revision history for this message
In , amichair (amichai2) wrote :

Also, using this technique it takes 53 seconds from running the command plasmashell until it's operational. Maybe the first 3 seconds is regular startup, then 50 second timeout on something?

also, in the terminal (where I run plasmashell) the last thing logged before it hangs is:

unversioned plugin detected, may result in instability
org.kde.plasma.pulseaudio: state callback

and the first thing after it resumes 50 seconds later is:

plasma-nm: Failed to enumerate BT adapters

I hope this helps.

Revision history for this message
In , U26 (u26) wrote :

>plasma-nm: Failed to enumerate BT adapters

That seems like it could be it.

can you run
dbus-monitor (or ideally bustle if you can install that) and launch plasmashell

Revision history for this message
In , amichair (amichai2) wrote :

If I understand the output of bustle correctly, there's nothing obviously wrong here.

There's one line at 2928 which is a method return value from PowerManagement.PolicyAgent.ListInhibitions, and the next line after it is at 53016 (that's the 50 seconds later) which is a request for NetworkManagement Introspect.

There don't appear to be any request/response crossing that line, so the time appears to be spent somewhere else, not stuck on a dbus transaction. The method durations statistics pane shows all durations at the millisecond level. Is that the kind of thing you're looking for?

Revision history for this message
oleoleole (ole-gidderikke) wrote :

This bug seems to be related to plasma-nm (plasma network manager). For me it took a long time before the "Edit connection" actually showed up, about the same time it took for me to boot into KDE.

So I tried to setup the network the old fashioned way with /etc/network/interfaces and removed plasma-nm, now it boots like before.

Luckily I don't need network-manager, so I can leave it like this. But if you run a laptop and want some easy setup with a network manager gui, than you should either wait for a fix, or try to use nm-applet found in gnomes network manager.

Now, you might still be able to run network-manager without plasma-nm, yet it seems to be related to plasma-nm app itself.

Revision history for this message
In , Pelzlurch (popanz) wrote :

It's definitely a BT-Problem. Putting in a BT-USB-Stick the desktop starts much faster.

Revision history for this message
In , U26 (u26) wrote :

Can you see if:
 - any of the lines in bustle were red

if so, the full output of that line.

 - screenshots of the statistics page

Message frequencies and Method Durations

Revision history for this message
In , U26 (u26) wrote :

oh bother, of couse you won't see anything

bustle is monitoring the session bus by default.
network manager is on the system bus

I don't think bustle has a UI for it, but

bustle-pcap --system somefile

then open it in bustle

Revision history for this message
In , amichair (amichai2) wrote :

Created attachment 95108
bustle output when panel hangs

I attached the bustle output. It starts just before starting plasmashell, and ends when it's all good. Nothing else going on in between. You can see the hang in the entries at the very bottom.

Revision history for this message
In , U26 (u26) wrote :

Thanks, in case you missed it I posted a comment 1 minute before you uploaded this realising I need something else.

Revision history for this message
vmagnin (vincent-magnin) wrote :

Thank you oleoleole,
I confirm that removing the network manager app from the taskbar solves the problem.

vmagnin (vincent-magnin)
description: updated
Revision history for this message
vmagnin (vincent-magnin) wrote :

removing the network manager app from the taskbar solves the problem.

affects: kde-runtime (Ubuntu) → plasma-nm (Ubuntu)
Revision history for this message
vmagnin (vincent-magnin) wrote :

Seems to be a duplicate of Bug #1509471, or to be related to.

Revision history for this message
In , amichair (amichai2) wrote :

Created attachment 95113
bustle output (pcap,system) when panel hangs

Thanks, I did miss that comment. Here it is. Quite short.

Revision history for this message
In , U26 (u26) wrote :

heh, that wasn't very useful. Has nothing from network manager or bluetooth which is where we think we want to be looking.

The interface must have sniffing turned off.

Does sudo bustle-pcap include anything better?

Altnernate approach is we go from the other side and run "gdb plasma"
then after 10s (where everything else should should be stopped)
type "control+c" "bt" and we find where plasma is blocked and waiting

If that's a bit much, I'll install Kubuntu 15.10 in a virtual machine which won't have bluetooth - and poke it there.

Revision history for this message
In , amichair (amichai2) wrote :
Download full text (4.7 KiB)

#0 0x00007ffff25d38dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007fffef11472f in () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#2 0x00007fffef1133ae in () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#3 0x00007fffef0fc014 in () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#4 0x00007fffef0fcacc in () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#5 0x00007fffef0fcfca in dbus_connection_send_with_reply_and_block () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#6 0x00007ffff7f62ad0 in () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7 0x00007ffff7f64316 in () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#8 0x00007ffff7f70dcd in () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#9 0x00007ffff7f70f15 in QDBusInterface::QDBusInterface(QString const&, QString const&, QString const&, QDBusConnection const&, QObject*) ()
    at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#10 0x00007fff36ed46c5 in Handler::isBtEnabled() () at /usr/lib/x86_64-linux-gnu/libplasmanm_internal.so
#11 0x00007fff36ed5cb4 in Handler::Handler(QObject*) () at /usr/lib/x86_64-linux-gnu/libplasmanm_internal.so
#12 0x00007fff3712c780 in () at /usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/networkmanagement/libplasmanm_qmlplugins.so
#13 0x00007ffff54816cb in QQmlType::create() const () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#14 0x00007ffff54e58fd in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#15 0x00007ffff54e7a8d in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#16 0x00007ffff54e7e2b in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#17 0x00007ffff54e459d in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#18 0x00007ffff54e4f81 in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#19 0x00007ffff54e60b4 in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#20 0x00007ffff546eec7 in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#21 0x00007ffff546f7b4 in QQmlIncubationController::incubateFor(int) () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#22 0x00007ffff61577ac in () at /usr/lib/x86_64-linux-gnu/libKF5Declarative.so.5
#23 0x00007ffff546f5c9 in QQmlEnginePrivate::incubate(QQmlIncubator&, QQmlContextData*) () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#24 0x00007ffff546ae0c in QQmlComponent::create(QQmlIncubator&, QQmlContext*, QQmlContext*) () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#25 0x00007ffff6147845 in KDeclarative::QmlObject::completeInitialization(QHash<QString, QVariant> const&) ()
    at /usr/lib/x86_64-linux-gnu/libKF5Declarative.so.5
#26 0x00007ffff799f658 in PlasmaQuick::AppletQuickItem::init() () at /usr/lib/x86_64-linux-gnu/libKF5PlasmaQuick.so.5
#27 0x00007fffcae665dc in () at /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/scriptengines/plasma_appletscript_declarative.so
#28 0x00007fffcae65bc9 in () at /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/scriptengines/plasma_appletscript_declarative.so
#29 0x00007ffff2ed7651 in QObject::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x00007ffff5ef410b in QQuickItem::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#31 0x00007fffcae66896 in () at /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/scriptengines/plasma_appletscript_declarative.so
#32 0x00007ffff3983b8c in...

Read more...

Revision history for this message
In , U26 (u26) wrote :

We can see we're making some blocking calls to BlueZ here.

    QDBusInterface managerIface("org.bluez", "/", "org.freedesktop.DBus.ObjectManager", QDBusConnection::systemBus(), this);

is blocking

    QDBusReply<QMap<QDBusObjectPath, NMVariantMapMap> > reply = managerIface.call("GetManagedObjects");

is blocking

                QDBusInterface adapterIface("org.bluez", objPath, "org.bluez.Adapter1", QDBusConnection::systemBus(), this);

is blocking

and finally

                const bool adapterEnabled = adapterIface.property("Powered").toBool();

Arguably bluez shouldn't be taking so long to respond, but I think we can turn this async. We need to handle an adaptor enabling at runtime regardless so we need to handle it changing in handler.cpp anyway

Revision history for this message
In , Jgrulich (jgrulich) wrote :

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

Revision history for this message
In , Jgrulich (jgrulich) wrote :

Git commit f3e940d49574b3d464b8d7118cdced136283579b by Jan Grulich.
Committed on 25/10/2015 at 16:37.
Pushed by grulich into branch 'master'.

Make all bluez calls asynchronous

REVIEW:125785

M +62 -55 libs/handler.cpp
M +3 -4 libs/handler.h

http://commits.kde.org/plasma-nm/f3e940d49574b3d464b8d7118cdced136283579b

Revision history for this message
In , Jgrulich (jgrulich) wrote :

Git commit 48a45ebad0e1d5ecc023a9e8866a95d47c76790f by Jan Grulich.
Committed on 25/10/2015 at 16:38.
Pushed by grulich into branch 'Plasma/5.4'.

Make all bluez calls asynchronous

REVIEW:125785

M +62 -55 libs/handler.cpp
M +3 -4 libs/handler.h

http://commits.kde.org/plasma-nm/48a45ebad0e1d5ecc023a9e8866a95d47c76790f

Revision history for this message
In , Jgrulich (jgrulich) wrote :

Can someone please test the fix? I wasn't able to reproduce this issue even without this fix so we need someone else to confirm that making bluez calls asynchronous helps. Thanks.

Revision history for this message
In , amichair (amichai2) wrote :

Is there a simple way to test it without modifying my system?

kiran (skirankumars31)
Changed in plasma-nm (Ubuntu):
assignee: nobody → kiran (skirankumars31)
assignee: kiran (skirankumars31) → nobody
Revision history for this message
In , Jgrulich (jgrulich) wrote :

Unfortunately no, you would need to compile plasma-nm or if you know how to make deb packages then you need just download the patch and make a new package.

Revision history for this message
David Edmundson (david.edmundson) wrote :

Please see https://bugs.kde.org/show_bug.cgi?id=354230 upstream.

Is fixed for 5.4.3.

I would suggest backporting that specific patch listed in the final comment.

Philip Muškovac (yofel)
Changed in plasma-nm (Ubuntu):
assignee: nobody → Philip Muškovac (yofel)
status: Confirmed → Triaged
Changed in plasma-nm (Ubuntu Wily):
assignee: nobody → Philip Muškovac (yofel)
Revision history for this message
In , Jgrulich (jgrulich) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in plasma-nm:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
In , Alex Sidorenko (asid) wrote :

Hello Jan,

I have build .deb on Kubuntu-15.10 applying your patches to plasma-nm_5.4.2-0ubuntu1 sources.

Everything works fast after that:
  - on login
  - clicking on systray applet
  - starting kde5-nm-connection-editor from shell

Many thanks for a quick fix!

Regards,
Alex

Revision history for this message
In , quess (quess) wrote :

Hello,

sorry I was away from my computer since 3 days.
Timeout seems not to be related to BT, since I have no BT. I created my-dbus-log as it was asked and attached it.
Have a look at time stamp 1445877558 near line 3074, dbus stops writing until timestamp 1445877595

Revision history for this message
In , quess (quess) wrote :

Created attachment 95141
my-dbus-log

Revision history for this message
In , Alex Sidorenko (asid) wrote :

Alex(In reply to quesseb from comment #29)

> Timeout seems not to be related to BT, since I have no BT.

I don't have BT either, but Jan's fix has resolved the problem on my host!

Alex

Revision history for this message
In , Jgrulich (jgrulich) wrote :

Plasma-nm makes bluez calls even when you don't have bluetooth to check whether you have it or don't and because the calls were blocking and bluez was not responding then start of plasma-nm was delayed.

Revision history for this message
In , Alex Sidorenko (asid) wrote :

Created attachment 95144
plasma-nm with Jan's fix built on kubuntu-15.10

I am not an "official" builder of packages but if anybody on Kubuntu-15.10 is interested in testing Jan's fix, this is what I built. It definitely resolves the problem for me - no delays anymore.

Revision history for this message
In , quess (quess) wrote :

asid, thank you so much for your deb, it works like a charm.
And thank you Jan for your ultra fast fix!!!

Philip Muškovac (yofel)
tags: added: kubuntu wily
Philip Muškovac (yofel)
Changed in plasma-nm (Ubuntu):
status: Triaged → Fix Committed
Changed in plasma-nm (Ubuntu Wily):
assignee: Philip Muškovac (yofel) → nobody
status: New → In Progress
Philip Muškovac (yofel)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: KDE/Plasma very slow to launch (Kubuntu 15.10)

This bug was fixed in the package plasma-nm - 4:5.4.2-0ubuntu2

---------------
plasma-nm (4:5.4.2-0ubuntu2) xenial; urgency=medium

  * Applying patch upstream_fix_making_bluez_asynchronous.diff
    from upstream to make all bluez calls asynchronous, patch
    by Jan Grulich <email address hidden> LP: #1509334

 -- Clive Johnston <email address hidden> Mon, 26 Oct 2015 16:14:16 +0000

Changed in plasma-nm (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
vmagnin (vincent-magnin) wrote :

I have enabled "wily-proposed" on the main server but there is no plasma-nm update by now.

Revision history for this message
In , kiran (skirankumars31) wrote :

Hi All,
          Im a newbie to all this patch fixing world. I can see from Asid's work in ubuntu packages that the latest patch is available for Xenial(Next version of Kubuntu). How do i make sure that that patches will be available for the current kubuntu version (15.10) ?. How do i propose the patch fix for kubuntu 15.10 ?

Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote :

Vincent, you are right – it sits in the proposed-queue … since 19 hours...

https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=

Something goes wrong here, probably?
Once it's landed in proposed, the package gets tagged "verification needed"

Not sure why the process is stuck...

Thanks for the fixing.

Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote :

So for the time beeing it has status "unapproved", currently.

Revision history for this message
In , U26 (u26) wrote :

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

Revision history for this message
In , Serhiy (xintx-ua) wrote :

Easier workaround is to purge all bluez packages. Obviously, you should do not only in case you don't need bluetooth support.

Revision history for this message
In , hugorteg (hugorteg) wrote :

I had the same problem on my desktop computer (without bluetooth) after the upgrade, but using a USB bluetooth adapter solves the problem.

Revision history for this message
Vertago1 (vertago1) wrote :

I downloaded the source package from the proposed queue and tested it, and it fixes the problem on my system. I am not sure if there are unintended side effects though. The long wait for plasmashell to finish loading was quite annoying. Thanks for the fix. It seems like this problem or similar ones keep coming back, where some startup process uses blocking calls and it slows the whole startup.

Revision history for this message
In , Philip Muškovac (yofel) wrote :

@kiran: the patch is pending for 15.10, but due to the procedure it'll take at least another week before you'll find the fix in your regular updates. In the meantime, the fix is in the kubuntu updates ppa (ppa:kubuntu-ppa/ppa)

(and to actually answer your question, the procedure it at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure and in this case, the relevant bug is http://pad.lv/1509334 )

Flames_in_Paradise (ellisistfroh-deactivatedaccount)
summary: + [sru] plasma-nm blocks temporarily on startup w/o bluetooth device –
KDE/Plasma very slow to launch (Kubuntu 15.10)
Revision history for this message
Chris J Arges (arges) wrote : Please test proposed package

Hello vmagnin, or anyone else affected,

Accepted plasma-nm into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/plasma-nm/4:5.4.2-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in plasma-nm (Ubuntu Wily):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Vertago1 (vertago1) wrote :

I tested the package:
ii plasma-nm 4:5.4.2-0ubuntu1.1 amd64 Plasma5 networkmanager library.
And it fixed the problem for me (#45)

tags: added: verification-done
removed: verification-needed
Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote :

Tested the 64-bit package too. Resolved another undectactable problem with hibernation/resume as well. Thanks for caring.

Revision history for this message
vmagnin (vincent-magnin) wrote :

The plasma-nm 4:5.4.2-0ubuntu1.1 amd64 package (wily-proposed) solved the problem on the two machines where I installed it,
BUT...
I now have another problem with the network manager app: after having reinstalled it in the systray, the window applet is now tiny, in fact of the same size as the icon ! And I found no way to change its size, so I can not use it...
Am I the only one with this problem ?

Revision history for this message
vmagnin (vincent-magnin) wrote :

In fact, the network manager app must not be reinstalled using the "Add Widgets..." menu (which causes the problem cited in my message #61), but with the "System Tray Settings..." menu (no problem in that case).
Thank you for the fix.

Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote :

Vincent,
u could try the most harmless method - resize the heigth of the taskbar, then it should adjust. Noone knows by what method u removed & reeinstalled(?) it from "system-notification".

Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote :

Vincent,
glad to see the hint helped u to fix the appearance in the taskbar. This is really the 1st time the reply appears b4 the answer is finished.

Taking into account this nuissant error is present now since more than a week we are obviously missing out on architectures other than 64-Bit to avoid any regression.

Vincent, amongst ur 4 machines any other architecture to confirm?

Revision history for this message
vmagnin (vincent-magnin) wrote :

Flames_in_Paradise,
it seems thought transmission is faster than light ;-)

The fix has solved the problem on two machines under Kubuntu 15.10 64 bits and one machine under Kubuntu 15.10 32 bits (but the CPU is 64 bits). I have no access to the 4th machine this week.

I have also noticed that on a 5th machine, a new laptop, the bug is not present, probably because it is my only machine with a bluetooth chip.

Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote :

Vincent,
easy to find out - just deactivate B-tooth on that laptop. On my desk-machine I were lucky enough to have a BT 4.0 stick lieeing next to it.

@Yofel: I don't have the rights for it, but I think one should really consider to pass this on "milestone-updates"

https://launchpad.net/ubuntu/+milestone/wily-updates

Since I dont know anybody doing the updates with a Live-DVD this bug would be present then without. This 30 seconds delay is a really unpleasant encounter ( just tested it with the final-DVD in VirtualBox) for this release. It gives a completely wrong impression for K5

Best regards

Revision history for this message
Vertago1 (vertago1) wrote :

@Flames_in_Paradise
I have tested:
plasma-nm 4:5.4.2-0ubuntu1.1 amd64
On a live CD by using the process detailed in https://help.ubuntu.com/community/LiveCDCustomization#Extract_the_CD_.iso_contents
and it fixed the problem and didn't seem to have any negative consequences.

I agree this fix should be pushed to the live cd for Kubuntu 15.10 or people will be turned away by how slow the desktop loads. Another change I recommend making is disabling the krunner option for "windowed widgets" which is enabled by default. This causes some kind of race condition which crashes krunner and plasmashell. I am not sure if anyone is working on a fix.

Revision history for this message
vmagnin (vincent-magnin) wrote :

@Flames_in_Paradise
I confirm that when I deactivate B-tooth on my laptop, the bug is then present. And disappears when I activate B-tooth.

I agree that this bug is annoying: it is not critical for someone at ease with Linux but newbies could run away from Kubuntu... And it is no chance it appeared one day before the final release !

Revision history for this message
Philip Muškovac (yofel) wrote :

I appreciate all the effort you guys are putting into the issue, but only LTS releases have point releases with refreshed installation images. For Wily the images are done and there's no option to generate new ones anymore.
I'm sorry that such an issue made it into the final release, but it seems that none of our very few pre-release image testers hit this issue during the milestone tests. (Maybe all used harware with bluetooth, or this doesn't happen in VMs, I don't know)

Flames_in_Paradise (ellisistfroh-deactivatedaccount)
summary: - [sru] plasma-nm blocks temporarily on startup w/o bluetooth device –
- KDE/Plasma very slow to launch (Kubuntu 15.10)
+ [regression] [sru] plasma-nm blocks temporarily on startup w/o bluetooth
+ device – KDE/Plasma very slow to launch (Kubuntu 15.10)
Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote : Re: [regression] [sru] plasma-nm blocks temporarily on startup w/o bluetooth device – KDE/Plasma very slow to launch (Kubuntu 15.10)

Could someone please report this to QA ISO-testing?

Revision history for this message
themroc (rauchweihe) wrote :

I cannot confirm this

"+ [regression] [sru] plasma-nm blocks temporarily on startup w/o bluetooth
+ device – KDE/Plasma very slow to launch (Kubuntu 15.10) "

on 2 Laptops with bluetooth devices and updated package plasma-nm - 4:5.4.2-0ubuntu2.

Plasma launch as fast as with bluetooth on or off: no difference.

Revision history for this message
vmagnin (vincent-magnin) wrote :

@themroc
Have you deactivated the bluetooth chip in the BIOS ?

Revision history for this message
themroc (rauchweihe) wrote :

@vmargin
I cannot deactivate the bluetooth chip in the BIOS, but I can deactivate the bluetooth chip via a hardware switch:

No problem if deactivate the bluetooth chip via a hardware switch before login, before boot, during plasma session, and so on.

Flames_in_Paradise (ellisistfroh-deactivatedaccount)
summary: - [regression] [sru] plasma-nm blocks temporarily on startup w/o bluetooth
- device – KDE/Plasma very slow to launch (Kubuntu 15.10)
+ [sru] plasma-nm blocks temporarily on startup w/o bluetooth device –
+ KDE/Plasma very slow to launch (Kubuntu 15.10)
tags: added: regression-release
Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote :

@Themroc: you are using Xenial already? The patch arrived there instantly.

This bugfix is a proper reaction on the fixing in bug #1506774:
 "bluez 5.35-0ubuntu1 failed to install/upgrade... (without linux-image-extra*)"

This bug here was introduced so, just before release and is within now.

Can be easily tested w/o applying this patch, just run the command:

$ sudo systemctl disable bluetooth.service #use enable to revert

@ Yofel: Milestone "Updates" is active for any release here alive. It's up to the dev's/ReleaseManager to report it here. Ideally until 14 days upon release.

I cannot recommend this Live-CD to anybody as a showcase - but I can show the difference between installing updates during installation eventually or not installing updates during installation.

Revision history for this message
Adam Baron (vysocan76) wrote :

Hello,

I can confirm after running:
$ sudo systemctl disable bluetooth.service

the system is starting fast again.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package plasma-nm - 4:5.4.2-0ubuntu1.1

---------------
plasma-nm (4:5.4.2-0ubuntu1.1) wily; urgency=medium

  * Applying patch upstream_fix_making_bluez_asynchronous.diff
    from upstream to make all bluez calls asynchronous, patch
    by Jan Grulich <email address hidden> LP: #1509334

 -- Clive Johnston <email address hidden> Mon, 26 Oct 2015 16:14:16 +0000

Changed in plasma-nm (Ubuntu Wily):
status: Fix Committed → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote : Update Released

The verification of the Stable Release Update for plasma-nm has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
In , U26 (u26) wrote :

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

Revision history for this message
In , Jgrulich (jgrulich) wrote :

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

Revision history for this message
Declan Mullen (declan-mullen) wrote :

Using Kubuntu 15.10 x64. No bluetooth hardware.
After the KDE login progress bar reaches 100%, it then takes 25 seconds before beginning the transition to the KDE desktop.
uninstalling network-manager and plasma-nm and disabling bluetooth.service has not reduced the 25 seconds delay.

Revision history for this message
Declan Mullen (declan-mullen) wrote :

25 second delay removed by by going into Settings/Start Up & Shutdown/Desktop Sessions/On Login and changing the setting to "Start with an Empty Session".

Revision history for this message
Allen Webb (vertago1-s) wrote :

@declan-mullen

Take a look at your $HOME/.kde/share/config/ksmserverrc file. If it wasn't overwritten since you changed to start with an empty session, is there anything odd in the [Session: saved at previous logout] section? You could also post it, but it will include your username which you may or may not mind posting online.

Revision history for this message
Bast (bast-bonnet) wrote :

@Allen Webb

Thanks for your advice. Her is what I tried :
1. I removed the ksmserverrc and checked "Start with an Empty Session" → Login process is much faster
2. I re-enabled "Restore previous session" → Login is slow again. No ksmserverrc file has been recreated. The programs arec correctly restored, though.

Seems like the problem lies in the "Restore previous session" functionnality.

Revision history for this message
Elias Kouskoumvekakis (eliaskousk) wrote :

I had the same symptoms and thought it was the plasma-nm package but realized that I already have the wily-updates fix that this report is all about.

Luckily I read the above (#80 - #83) and just selected in System Settings -> Startup and Shutdown -> Desktop Session tab -> On Login section -> Start with an empty session (it was set before as Restore previous session).

Everything is fine now and I don't have to wait for half a minute looking at the KDE login progress bar.

Shouldn't we submit this info elsewhere? I searched and couldn't find a matching bug report, thanks.

Revision history for this message
xprt64 (xprt64) wrote :

The solution provided by Declan Mullen worked for me:

Settings/Start Up & Shutdown/Desktop Sessions/On Login and changing the setting to "Start with an Empty Session"

Now, the KDE starts up very fast.

Revision history for this message
Alejandro Palacios (pamanes7) wrote :

I can confirm the problem, I installed kubuntu yesterday and it take about 30 seconds to get a usable desktop. I will try "empty session" solution and report.

Revision history for this message
Alejandro Palacios (pamanes7) wrote :

the empty session works! it brought the startup from 30-ish seconds down to nothing!

thanks a lot!

Revision history for this message
mpGoodwin (martin-launchpad-goodwin) wrote :

I dislike necroposting on a subject that seems to be resolved, but I have just upgraded to xenial in the hope that this annoying login delay would at long last be resolved, but even though my plasma-nm is at 4:5.5.5-0ubuntu1, it still has a 20 second delay after reaching approximately 100% progress on login. This is even true with the "use empty session" advice given in #81. How do I generate more useful data for triaging this behaviour

Revision history for this message
Flames_in_Paradise (ellisistfroh-deactivatedaccount) wrote :

hi! mpGoodwin,

see comments #4,5 in bug #1478322 (SDDM init is slow with SDDM theme Breeze) - even though it's the plasma init then.

May it's best to continue there then, even though bug-reports are not the ideal places for discussing.

Revision history for this message
Twisted Lucidity (lucidlytwisted) wrote :

I am also seeing a long delay after entering my password. Long enough for clients to fail as I am unable to enter my KWallet password within their timeout period.

I have tries "systemd-analyze", but that only seems to cover the boot process and not login.
The headline from it is: Startup finished in 6.599s (kernel) + 8.008s (userspace) = 14.608s

I sat with a stopwatch and manually timed things.
From cold-boot (including POST etc) it took 18 seconds to see the login screen.
After enter my password and pressing "Enter" at the login screen, it took 32 seconds to see the desktop. For a vast majority of this time, the progress bar sat at 100% and nothing appeared to be happening.

I've been trying to get get "systemd-bootchart" to show me what happens after login, but I think it only captures the boot process.
Is there any way for me to capture what is causing login to be so slow? I tried to look at https://wiki.ubuntu.com/BootCharting (mentioned in #1353587) but it is missing.

Revision history for this message
Twisted Lucidity (lucidlytwisted) wrote :

Apols for quick second post.

At login, the progress bar is filled within around 4-6 seconds, the desktop does not appear until around 24 seconds later.

The "empty session" trick from #81 has no effect, it stil take 30-32 seconds in total to get to the desktop.

Revision history for this message
Martin (martinitram) wrote :

Hi,

I also have the 30s delay since the upgrade to 16.04. I removed all bluez packages with no success. I even removed the packages plasma-nm and network-manager, did a reboot but still got the 30s delay. Do you have any ideas?

Revision history for this message
NS Koomar (ns-koomar) wrote :

Same issue. Not even a upgrade. Clean fresh 16.04 install. Worked great for a week or so. Plagued with this annoying bug. Tried everything on this post to no help. Considering moving to another distro.

Revision history for this message
Martin (martinitram) wrote :

My backup plan is to use packages from http://neon.kde.org/ when it got stable.

Revision history for this message
Philip Muškovac (yofel) wrote :

To everyone that recently posted on this bug:

First of, thank you for taking your time to report your issues and helping to make Kubuntu better, but if you experience a slow login issue, please open a new report. This bug is specifically for an issue with detection of bluetooth devices in plasma-nm and not a general slow login issue collection tracker. This specific bug was fixed in 15.10 and is closed.

Thank you

Revision history for this message
Martin (martinitram) wrote :

I would do it but I do not know to which package...

Revision history for this message
Con Kolivas (kernel-kolivas) wrote :

I've opened a new bug for those who still have a similar problem with kubuntu 16.04 since this one was closed as being fixed:
https://bugs.launchpad.net/ubuntu/+source/plasma-nm/+bug/1584604

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.