After updating my Fedora-27 system to kde-5.12.2/5.12.3 - the time from login to desktop took a noticeable hit. While 5.11 was already quite slow compared to Gnome or XFCE, with 5.12 there is definitivly something wrong (especially keeping in mnid the changes in 5.12 to actually *improve* startup time). What are the preferred was to gather additional information? Is there any way to find out for what event plasma is waiting during startup?
This is not always true (slow startup), I can get in to a plasma session on my older f27 laptop in just a few seconds (admittedly, using ssd here helps a lot!). Posting the contents of your ~/.xsession-errors may help
This seems somehow linked to my hardware configuration - I am using the same SSD on both my desktop PC as well as my notebook (this way I don't have to take care syncing two systems, while I still get the benefits of a more powerful desktop PC). Desktop System: AMD Kaveri 7650k, AMD GCN apu (radeonsi + amdgpu), 4k monitor on HDMI, FHD monitor connected via DVI Laptop: Elitebook 2540po, Core i5 540M, Intel HD Graphics (GEN 5) When booting the system on the Elitebook, kde starts pretty fast - on the deksop system I can watch the start animation spin for ~30s. Maybe this has something to do with probing monitors? I'll try gathering some additional information. My xsession-errors seems clean after booting the desktop system: startkde: Starting up... 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/disable_kmix.upd' for new updates 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/fonts_akregator.upd' for new updates 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/fonts_global.upd' for new updates 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/fonts_global_toolbar.upd' for new updates 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/fonts_kate.upd' for new updates 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/gtkbreeze5.5.upd' for new updates 2018-03-31T22:13:57 gtkbreeze5.5.upd: Found new update 'GTKBreeze5.5' 2018-03-31T22:13:57 gtkbreeze5.5.upd:3:'Script=gtkbreeze5.5': Script 'gtkbreeze5.5' not found 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/krdb_libpathwipe.upd' for new updates 2018-03-31T22:13:57 krdb_libpathwipe.upd: Found new update 'LibraryPathWipeOut' 2018-03-31T22:13:57 krdb_libpathwipe.upd:3:'Script=krdb_clearlibrarypath': Script 'krdb_clearlibrarypath' not found 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/krunnerplugins.upd' for new updates 2018-03-31T22:13:57 krunnerplugins.upd: Found new update '5.9KRunnerPlugins' 2018-03-31T22:13:57 krunnerplugins.upd:3:'Script=krunnerplugins': Script 'krunnerplugins' not found 2018-03-31T22:13:57 Checking update-file '/usr/share/kconf_update/kscreenlocker.upd' for new updates vmware-user: could not open /proc/fs/vmblock/dev (uint32 1,) Cannot save the changes made to the configuration Successfully migrated abrt-applet:AutoreportingEnabled to org.gnome.desktop.privacy:report-technical-problems OpenGL vendor string: X.Org OpenGL renderer string: AMD KAVERI (DRM 3.23.0 / 4.15.13-300.fc27.x86_64, LLVM 5.0.1) OpenGL version string: 4.5 (Core Profile) Mesa 17.3.6 OpenGL shading language version string: 4.50 Driver: Unknown GPU class: Unknown OpenGL version: 4.5 GLSL version: 4.50 Mesa version: 17.3.6 Linux kernel version: 4.15.13 Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no
Can I see your ~/.local/share/sddm/xorg-session.log output
I am using lightdm, so the file you asked for is not present. However, this is the content of /var/log/lightdm.log: [+0.00s] DEBUG: Starting Light Display Manager 1.25.1, UID=0 PID=1094 [+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-backup-logs.conf [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-disable-guest.conf [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-minimum-vt.conf [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-session-wrapper.conf [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-user-authority-in-system-dir.conf [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/60-lightdm-gtk-greeter.conf [+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf [+0.00s] DEBUG: [LightDM] contains unknown option autologin-user [+0.00s] DEBUG: Registered seat module local [+0.00s] DEBUG: Registered seat module xremote [+0.00s] DEBUG: Registered seat module unity [+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager [+0.01s] DEBUG: Monitoring logind for seats [+0.01s] DEBUG: New seat added from logind: seat0 [+0.01s] DEBUG: Seat seat0: Loading properties from config section Seat:* [+0.01s] DEBUG: Seat seat0: Starting [+0.01s] DEBUG: Seat seat0: Creating user session [+0.01s] DEBUG: Loading users from org.freedesktop.Accounts [+0.01s] DEBUG: User /org/freedesktop/Accounts/User1000 added [+0.07s] DEBUG: Seat seat0: Creating display server of type x [+0.07s] DEBUG: Deactivating Plymouth [+0.09s] DEBUG: Using VT 1 [+0.09s] DEBUG: Seat seat0: Starting local X display on VT 1 [+0.09s] DEBUG: XServer 0: Logging to /var/log/lightdm/x-0.log [+0.09s] DEBUG: XServer 0: Writing X server authority to /var/run/lightdm/root/:0 [+0.14s] DEBUG: XServer 0: Launching X Server [+0.14s] DEBUG: Launching process 1102: /usr/bin/X -core -noreset :0 -seat seat0 -auth /var/run/lightdm/root/:0 -listen tcp vt1 -novtswitch -background none [+0.14s] DEBUG: XServer 0: Waiting for ready signal from X server :0 [+0.14s] DEBUG: Acquired bus name org.freedesktop.DisplayManager [+0.14s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0 [+1.38s] DEBUG: Got signal 10 from process 1102 [+1.38s] DEBUG: XServer 0: Got signal from X server :0 [+1.38s] DEBUG: XServer 0: Connecting to XServer :0 [+1.39s] DEBUG: Quitting Plymouth; retaining splash [+1.41s] DEBUG: Seat seat0: Display server ready, starting session authentication [+1.41s] DEBUG: Session pid=1117: Started with service 'lightdm-autologin', username 'ce' [+1.44s] DEBUG: Session pid=1117: Authentication complete with return value 0: Success [+1.44s] DEBUG: Seat seat0: Session authenticated, running command [+1.44s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0 [+1.44s] DEBUG: Session pid=1117: Running command /etc/X11/xinit/Xsession /usr/bin/startkde [+1.44s] DEBUG: Creating shared data directory /var/lib/lightdm-data/ce [+1.44s] DEBUG: Session pid=1117: Logging to .xsession-errors [+1.50s] DEBUG: Activating VT 1 [+1.50s] DEBUG: Activating login1 session 1 [+1.50s] DEBUG: Seat seat0 changes active session to 1 [+1.50s] DEBUG: Session 1 is already active
Then how about ~/.xsession-errors ?
already posted above
I could try to get stacktraces during boot - any idea which processes I should monitor?
KDE startup on my dual-screen AMD system: https://youtu.be/F4uIm3LVIwg KDE startup on my old intel notebook: https://youtu.be/JvJPieBXNpo Both systems have exactly the same software configuration, as I use one SSD (Crucial MX500) for both systems and swap it.
Thanks for the updates; changing status for inspection by Plasma developers.
I'm having a similar issue. The login is very fast if I configure Appearance/Workspace Theme/Splash Screen to "none". Any other splash screen causes 30+ seconds delay kde 5.12.90/Frameworks 5.46/Qt 5.11_rc2. Now it is a fairly recent system, running on gentoo, but this issue is present since at least a couple of months, so with older setups: qt 5.9.5 and previous, kde 5.11 and prev and so on. Is there any way I can debug or at least know what is going on while waiting? any debug log or similar? Thanks.
I can confirm this issue disappears as soon as I set "splash screen" to none. So instead of some display detection code being buggy, it seems something as ordinary as the splash screen is causing this issue. @Fabio: do you also experience this only on multi-display setups?
Unfortunately right now I have no access to my laptop, I will in a week. However I'm pretty sure that it is happening regardless of how many monitors I connect. IIRC, it is the same with only the internal screen or with one or two external monitors connected. However, v in a few days I will be able to check this.
Ok, I just checked and I have to say that with one monitor the issue did not happened, contrary to what I was remembering. I'll make some more test to see If I can spot a pattern.
I can confirm that is indeed taking more than 30 seconds to reach the desktop. KDE neon 5.13.2 UE , KDE Frameworks 5.47.0 , QT 5.11, Nvidia 390.67 In this case is taking 50 seconds from the startup screen until plasmashell loads. No Splash screen is being used (none). In this period of time i get a black screen background with my current cursor for 50 seconds then the desktop loads and works as expected. When autologin is being used (as normally) the only difference is that the login screen will seem to be waiting to "verify" the password for 50 seconds then plasmashell will start. Initially i was thinking it was a problem with Kscreenlocker, until i disabled the autologin on SSDM options and got the same 50 seconds. Some extra details: It started when the kernel on neon updated to 4.15.0-24-generic. Before that it took like 5 seconds to load the desktop. Removing the proprietary drivers make no difference same as on the intel open driver. Under a Wayland session (intel and nvidia) the login works as expected it only takes like a few seconds. Plasmashell loads in 3 seconds after the password is typed in.
I have the same problem on my Fedora w/ a self-built Plasma. It started about a month or two ago. I'll see if I can find out something.
*** Bug 393352 has been marked as a duplicate of this bug. ***
Bug 399175 Seems to be relevant/duplicate.
Please get a bootchart as per http://blog.davidedmundson.co.uk/blog/plasma-startup/
*** Bug 399175 has been marked as a duplicate of this bug. ***
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Will try to reproduce the bug and provide data today.
I have been able to replicate the issue only now, so you can infer that it does not happens all the time. I'm attaching a couple of bootcharts that I've obtained. The most recent one has been captured when it took close to 20s to complete the login process. I had a quick look at the graphs and one thing I spotted is that everything starts more or less in the same whay, however ksplashqml takes much more time to complete. Not sure how to read the numbers (bar length compared to square bracketed numbers). I didn't looked in more detail, so I be missing something obvious, but it seems that splash simply does not gets out of the way when it should.
Created attachment 115973 [details] bootchart-short Chart with short waiting time
Created attachment 115974 [details] bootchart-long Bootchart with long waiting time
Thanks for the update; changing status for inspection.
Created attachment 118732 [details] With Splash Slow boot
Created attachment 118733 [details] Without Splash fast boot
Kubuntu 18.10/19.04 are also suffering from splash screen delaying desktop display. Attached boot chart with and without splash enabled. BTW, charts captured on a single screen laptop (Dell 7559 booting with Intel video).
Created attachment 118734 [details] with Splash and auto login disabled Boots quickly to desktop when auto login is not enabled.
Since yesterday im no longer affected by this issue the time has been reduced to about 5 seconds even with the splash login active. KDE Neon User edition Plasma Version: 5.15.5 KDE Frameworks: 5.58.0 Qt Version : 5.12.0
*** This bug has been marked as a duplicate of bug 424408 ***