Bug 1269004 - plasma-workspace 5.4.1-3-fc22 has a delay over 20 seconds upon login
plasma-workspace 5.4.1-3-fc22 has a delay over 20 seconds upon login
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: plasma-workspace (Show other bugs)
22
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: KDE SIG
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-05 18:11 EDT by C6563
Modified: 2016-07-19 15:57 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 15:57:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
packages that if updated cause the delay (2.36 KB, text/plain)
2015-10-05 18:11 EDT, C6563
no flags Details
.xsession-errors when the hang occurs (19.22 KB, text/plain)
2015-10-07 06:47 EDT, C6563
no flags Details
.xsession-errors where there is no hang (19.67 KB, text/plain)
2015-10-07 06:47 EDT, C6563
no flags Details
Snapshot of .config/plasma-org.kde.plasma.desktop-appletsrc when desktop was good (18.66 KB, text/plain)
2015-10-21 09:42 EDT, Fredy Neeser
no flags Details
Snapshot of .config/plasma-org.kde.plasma.desktop-appletsrc when widgets were not showing (18.66 KB, text/plain)
2015-10-21 09:43 EDT, Fredy Neeser
no flags Details
~/.xsession-errors for first login after boot, with full debug output, including timing info (96.27 KB, text/plain)
2015-10-21 10:11 EDT, Fredy Neeser
no flags Details
~/.xsession-errors for first login after boot, filtered to only show kwin_core & kscreen (18.10 KB, text/plain)
2015-10-21 10:12 EDT, Fredy Neeser
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 353203 None None None Never

  None (edit)
Description C6563 2015-10-05 18:11:11 EDT
Created attachment 1080082 [details]
packages that if updated cause the delay

Description of problem: When logging in with Fedora 22 KDE Spin, with a fully updated system running plasma-workspace/5.4.1-3.fc22 there is a huge delay when the session is loading. There's a hang from 20 to 50 seconds and the progress bar is stuck during that time.

Version-Release number of selected component (if applicable):
 plasma-desktop 5.4.1-2.fc22.1
 plasma-workspace 5.4.1-3.fc22 

How reproducible:
Just update the system and the problem will occur.


Actual results:


Expected results: No delay after entering the password and hit enter.


Additional info:
I tried to downgrade systemd and polkit as suggested in #fedora. Did not solve.
The only step that solved the problem was to "dnf downgrade plasma-workspace --allowerasing"

Attatched is the output of dnf with the packages that dnf wants to re-update, that are the cause of the hang.

looks like more people are afected in the following thread: http://forums.fedoraforum.org/showthread.php?p=1744621

I have the same problem with more than one machine running Fedora
Comment 1 C6563 2015-10-05 18:14:25 EDT
I've downgraded to these versions:
kf5-baloo-5.9.0-1.fc22.x86_64
kf5-baloo-file-5.9.0-1.fc22.x86_64
plasma-desktop-5.3.0-5.fc22.x86_64
plasma-workspace-5.3.0-4.fc22.x86_64
polkit-0.112-9.fc22.x86_64
polkit-kde-5.3.0-1.fc22.x86_64
polkit-libs-0.112-9.fc22.x86_64
Comment 2 C6563 2015-10-06 18:43:46 EDT
A few more information about this:
-A friend who also runs Fedora 22 now also has same problem

-I tried to set the environment variable "LIBGL_DRI3_DISABLE=1" as suggested in https://forum.kde.org/viewtopic.php?f=289&t=124492 with no success

-I've tried to install 5.4.2 preview builds, using "yum-deprecated --enablerepo=updates-testing --advisory=FEDORA-2015-555ed68cfa update".

-Clean /tmp and use a new user session

-Rebuild font cache as suggested in a few forums with "sudo fc-cache -fv"

-Disable the Compositor

The only fix until now is to downgrade to the packages in Comment 1
Comment 3 C6563 2015-10-07 06:46:43 EDT
Very rarely the session starts without any loading hang. I captured an .xsession-errors when the hang happens and where it does not.

The only thing that looks a bug is this line that happens when the loading session hangs:

"autoStart2Done timedout, this is a BUG!"

Added two new attachments: xsession-hang.log and xsession-no-hang.log
Comment 4 C6563 2015-10-07 06:47 EDT
Created attachment 1080595 [details]
.xsession-errors when the hang occurs
Comment 5 C6563 2015-10-07 06:47 EDT
Created attachment 1080596 [details]
.xsession-errors where there is no hang
Comment 6 Rex Dieter 2015-10-07 07:42:03 EDT
Maybe try plasma-workspace-5.4.2-4 as part of
https://bodhi.fedoraproject.org/updates/FEDORA-2015-6b26456127
(hasn't been pushed yet), to see if that helps.  The prior 5.4.2 build had an error in the startkde script that caused important environment variables from not being set properly.

The fix was:
--- /usr/bin/startkde.orig      2015-10-07 06:41:29.689658408 -0500
+++ /usr/bin/startkde   2015-10-05 14:23:06.101597664 -0500
@@ -164,7 +164,7 @@
 # Add /env/ to the directory to locate the scripts to be sourced
 for prefix in `echo $scriptpath`; do
   for file in "$prefix"/env/*.sh; do
-    (test -r "$file" && . "$file") || :
+    test -r "$file" && . "$file" || :
   done
 done
Comment 7 Rex Dieter 2015-10-07 09:31:31 EDT
Could be this issue, 
https://bugs.kde.org/show_bug.cgi?id=353203
(the symptoms are similar)

with newer kf5-kservice-5.14.3, though that is not inline with comment #1
Comment 8 C6563 2015-10-07 11:31:04 EDT
I applied the patch in Comment 6, didn't help.
About the Comment 7 I have no way to test it.

However while digging the autostart I have new findings:
Workarround:
# cd /etc/xdg/autostart
# mkdir disabled
# mv * disabled
# mv disabled/plasmashell.desktop

This way there's NO delay when login in.
However, moving back any file from the disabled folder back to /etc/xdg/autostart will cause the delay. 
This is, having more than one file in /etc/xdg/autostart brings back the delay.

I accept any new ideas to try to fix this.
Comment 9 Rex Dieter 2015-10-07 12:09:13 EDT
following the lead on 
https://bugs.kde.org/show_bug.cgi?id=353203

I did a controlled downgrade to kf5-kserivce-5.13.0 (and expunging my sycoca cache), and that seemed to help (most of?) the delays I was seeing.

Could also be related to
https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=9c109e902b5b0658df67fdb3769c672fedd9e87e

since most of those seeing this are also getting the new
"autoStart2Done timedout, this is a BUG!"
message, but this may just be a side-effect of slow loading too.
Comment 10 C6563 2015-10-07 15:07:08 EDT
I confirm this. 

Downgraded from kf5-kservice-5.14.3-1.fc22.x86_64 to kf5-kservice-5.9.0-1.fc22.x86_64 and absolutely no lags during the load of the session.
Comment 11 C6563 2015-10-08 05:52:16 EDT
In the upstream bug, this comment https://bugs.kde.org/show_bug.cgi?id=353203#c11 is not a useful test case. At least for me.

The hang occurs only when performing a login with a fresh boot. If I login, have the hang and logout, the next logging without reboot does not hang when loading.

The only way I've found so far to trigger it is to reboot and login.
Comment 12 C6563 2015-10-15 11:55:09 EDT
It looks like kde frameworks 5.15 (and also kf5-kservice 5.15.0-1.fc22) fixed the problem for me.

Could anyone confirm?
Comment 13 Beat Küng 2015-10-19 03:23:28 EDT
Hi

I had the same problem: login delay of 30 seconds and "autoStart2Done timedout, this is a BUG!" entry in .xsession-errors - even with a newly created user.
upgrading to 5.15 indeed resolved the issue for me, using:
dnf --enablerepo=updates-testing upgrade kf5-\* plasma-{desktop,workspace}
Comment 14 Fredy Neeser 2015-10-20 06:11:43 EDT
(In reply to C6563 from comment #12)
> It looks like kde frameworks 5.15 (and also kf5-kservice 5.15.0-1.fc22)
> fixed the problem for me.
> 
> Could anyone confirm?

I had very similar symptoms, and yes, upgrading to kde frameworks 5.15 (as in Comment 13) fixed the problem for me, too !!!

As of today, I'm on a fully updated Fedora 22, with just these exceptions:
- Newer kde frameworks 5.15, from updates-testing
- Kernel 4.1.3-201.fc22.x86_64 (external monitor is not working for me
  with any of the more recent kernels)

This is a laptop with Intel + Nvidia GPUs, and the external monitor is driven by nouveau. The KDE desktop now works on the first login after boot.  The external monitor is my primary display, and the LVDS works as well. Logout/login works as well -- this didn't always result in a working KDE desktop previously.

The symptoms I had observed previously with kf5* 5.14.0 (since about Oct. 5, when I had upgraded to kf5* 5.14.0-1.fc22) were the following:

* Long lag during KDE logins

* During the first KDE login after boot, KDE typically changed its mind regarding the Primary Display and visibly moved it from LVDS to the external monitor.

* The first KDE login after boot usually resulted in a broken desktop on the external monitor, without any widgets, but with a KDE panel. Sometimes the KDE menu did not react when I clicked on it. Also, the LVDS was working but its background remained black.

* A logout/login cycle often helped to "fix" the KDE desktop, i.e., it often restored the widgets and the LVDS background. Sometimes more than one logout/login cycle was necessary.

* Most KDE logins (but particularly the first one after reboot) were accompanied by a crash of either
- kf5-kactivities or
- plasmashell
Comment 15 Fredy Neeser 2015-10-20 06:31:27 EDT
In my .xsession-errors, I previously also had an "autoStart2Done timedout, this is a BUG!" entry, which is now gone.

OTOH, it now shows some errors that were not present with kde frameworks 5.14:

* KActivities: FATAL ERROR: Failed to contact the activity manager daemon
* basic_code_modules.cc:70: ERROR: Module /lib64/libudev.so.1 could not be stored
  ???

B.t.w., the frequent crashes of kf5-kactivities during KDE login, which I had observed previously -- see for instance

  https://bugzilla.redhat.com/show_bug.cgi?id=1266774
  [abrt] kf5-kactivities: kactivitymanagerd killed by SIGSEGV

  https://bugzilla.redhat.com/show_bug.cgi?id=1210559
  [abrt] kf5-kactivities: _dl_fixup(): kactivitymanagerd killed by SIGSEGV

might well be related to the present bug.  Based on

  "KActivities: FATAL ERROR ...",

something is still wrong with kf5-kactivities.
Comment 16 Fredy Neeser 2015-10-20 16:26:10 EDT
(In reply to Fredy Neeser from comment #14)

> I had very similar symptoms, and yes, upgrading to kde frameworks 5.15 (as
> in Comment 13) fixed the problem for me, too !!!

Unfortunately, I declared victory too soon: Here are the results of some additional testing, using kernel 4.1.3-201.fc22.x86_64 in all cases:

* Boot (warm start)
  - Login to KDE
    - kactivitymanagerd crashes
    - kf5-kactivities crashes
    - KDE desktop broken (no widgets on primary display, LVDS remains black)

  - Logout/login
    - Again, KDE desktop broken

  - Logout/login
    - plasma-workspace crashes at login
    - KDE desktop recovers

* Boot (cold start)
  - Login to KDE
    - kactivitymanagerd crashes
    - KDE desktop works (widgets & panel on ext. monitor, LVDS has blue bg)


Overall, the chances to get a working KDE desktop have gone up a bit by going from KDE frameworks 5.14 to 5.15, but it looks like there are race conditions, which break KDE login quite often.
Comment 17 Fredy Neeser 2015-10-21 09:39:39 EDT
GOOD NEWS!

Further testing today with package versions as in Comment 14 and again using kernel 4.1.3-201.fc22.x86_64 shows more stable behavior in logout/login cycles, and finally seems to reveal what's going wrong in first logins after boot -- read on:

First I tested some logout/login cycles:

* Resume from sleep:
  - KDE desktop OK
  - 4 logout/login cycles all successful:
    - Login is pretty fast
    - No crash handlers are popping up
    - KDE desktop OK
      - External monitor shows panel and widgets on "caribbean" wallpaper
      - LVDS shows blue wallpaper

There is still one problem at the first KDE login after boot, as observed previously by others and myself:

* Reboot (warmstart)
  1. Login to KDE
  2. Panel and widgets first appear on LVDS
  3. Panel and widgets are visibly being moved to external monitor
  4. - External monitor: Widgets disappear, a blue wallpaper is shown instead;
       a KDE panel is still present and the KDE menu is working
     - LVDS: Turns black (no wallpaper), but windows moved to it are shown

Event #3 suggests that the external monitor (driven by nouveau) activates a bit later than the LVDS, which may give KDE's kscreen some trouble to select the correct screen configuration.  In fact the external monitor is a DELL U2713H, which quickly goes to Power Save mode when it has no signal on the DP -- which is the case right before login (SDDM login screen is on the LVDS only).

Event #4: Why do the widgets and the "caribbean" wallpaper disappear?
Hmm, last night I came across this bug:

  https://bugs.kde.org/show_bug.cgi?id=351079
  Spontaneously adding desktop containments at startup

which inspired me to take a snapshot of
  ~/.config/plasma-org.kde.plasma.desktop-appletsrc

right before the above reboot, when the desktop was OK:
   plasma-org.kde.plasma.desktop-appletsrc.widgets-ok

and then another snapshot when widgets were not showing:
  plasma-org.kde.plasma.desktop-appletsrc.widgets-not-showing

(see attachments) and ... BINGO, the only difference is:

widgets-ok
----------
[Containments][9][Wallpaper][org.kde.image][General]
height=1080
width=1920

widgets-not-showing
-------------------
[Containments][9][Wallpaper][org.kde.image][General]
height=1440
width=2560

As shown by xrandr, my LVDS is 1920x1080, whereas the external monitor on DP has dimensions 2560x1440, so it seems that in the "widgets-not-showing" case, the blue wallpaper is simply assigned to the wrong display -- which is backed by the observation that the LVDS turns black in event #4.

So the blue wallpaper is then shown on the external monitor, hiding the "caribbean" wallpaper and the widgets underneath.
Comment 18 Fredy Neeser 2015-10-21 09:42 EDT
Created attachment 1085136 [details]
Snapshot of  .config/plasma-org.kde.plasma.desktop-appletsrc  when desktop was good
Comment 19 Fredy Neeser 2015-10-21 09:43 EDT
Created attachment 1085137 [details]
Snapshot of  .config/plasma-org.kde.plasma.desktop-appletsrc  when widgets were not showing
Comment 20 Fredy Neeser 2015-10-21 09:45:34 EDT
I should add that a logout/login cycle magically fixes .config/plasma-org.kde.plasma.desktop-appletsrc ... and the widgets and "caribbean" wallpaper are again showing.
Comment 21 Fredy Neeser 2015-10-21 10:11 EDT
Created attachment 1085140 [details]
~/.xsession-errors for first login after boot, with full debug output, including timing info
Comment 22 Fredy Neeser 2015-10-21 10:12 EDT
Created attachment 1085143 [details]
~/.xsession-errors for first login after boot, filtered to only show kwin_core & kscreen
Comment 23 Fredy Neeser 2015-10-21 10:23:42 EDT
(In reply to Fredy Neeser from comment #22)
> Created attachment 1085143 [details]
> ~/.xsession-errors for first login after boot, filtered to only show
> kwin_core & kscreen

% The debug events confirm that kwin_core starts out with 1 screen:

2015-10-21T14:16:53 kwin(2169)/kwin_core unknown: screens:  1 desktops:  4


% A few seconds later, kscreen detects that there are actually 2 screens:

2015-10-21T14:17:19 kded5(2148)/kscreen.kded unknown: Config KScreen::Config(0xdd3450) is ready
2015-10-21T14:17:19 kded5(2148)/kscreen.kded unknown: Applying config
2015-10-21T14:17:19 kded5(2148)/kscreen.kded unknown: Calculating config ID for KScreen::Config(0xdd3450)
2015-10-21T14:17:19 kded5(2148)/kscreen.kded unknown: 	Part of the Id:  "f441c90d7fff980119e38f0644634f63"
2015-10-21T14:17:19 kded5(2148)/kscreen.kded unknown: 	Part of the Id:  "146c2efdcf57afd9a0298f07e8225d6b"
2015-10-21T14:17:19 kded5(2148)/kscreen.kded unknown: 	Config ID: "3b747aa080fb1f5741ac221a996d28eb"
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: Calculating config ID for KScreen::Config(0xdd3450)
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: 	Part of the Id:  "f441c90d7fff980119e38f0644634f63"
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: 	Part of the Id:  "146c2efdcf57afd9a0298f07e8225d6b"
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: 	Config ID: "3b747aa080fb1f5741ac221a996d28eb"
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: Applying known config "3b747aa080fb1f5741ac221a996d28eb"
2015-10-21T14:17:20 kded5(2148)/kscreen unknown: Primary output changed from KScreen::Output(Id: 102 , Name: "DP-1-2" ) ( "DP-1-2" ) to KScreen::Output(Id: 102 , Name: "DP-1-2" ) ( "DP-1-2" )
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: Finding a mode for QSize(2560, 1440) @ 59.9506
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: 	Found:  "105"   QSize(2560, 1440) @ 59.9506
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: Finding a mode for QSize(1920, 1080) @ 60.0209
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: 	Found:  "177"   QSize(1920, 1080) @ 60.0209
2015-10-21T14:17:20 kded5(2148)/kscreen unknown: Primary output changed from KScreen::Output(Id: 102 , Name: "DP-1-2" ) ( "DP-1-2" ) to KScreen::Output(NULL) ( "none" )
2015-10-21T14:17:20 kded5(2148)/kscreen unknown: Primary output changed from KScreen::Output(Id: 102 , Name: "DP-1-2" ) ( "DP-1-2" ) to KScreen::Output(Id: 102 , Name: "DP-1-2" ) ( "DP-1-2" )
2015-10-21T14:17:20 kded5(2148)/kscreen.kded unknown: doApplyConfig()
2015-10-21T14:17:21 kwin(2169)/kwin_core unknown: Vertical Refresh rate  60 Hz ( "primary screen" )
2015-10-21T14:17:21 kwin(2169)/kwin_core unknown: Vertical Refresh rate  60 Hz ( "primary screen" )
2015-10-21T14:17:21 kwin(2169)/kwin_core unknown: Vertical Refresh rate  60 Hz ( "primary screen" )
2015-10-21T14:17:21 kwin(2169)/kwin_core unknown: screens:  2 desktops:  4

At that point, "Primary output" is changing ... and this is where the blue wallpaper is apparently assigned to the wrong screen.
Comment 24 Kirys 2015-10-21 13:08:44 EDT
My configuration with the update package show the same kind of "wrong screen assignment".
I have 3 monitors and the official primary is the center one.
At some login the widget change locations: most of the time the one on the primary monitors merge with the ones on the right monitor.
And, no matter what some kde dialog like the logout one) always shows on the  monitor on the right, no matter what monitor is the primary or have mouse/focus.
Comment 25 Fredy Neeser 2015-10-29 10:21:19 EDT
The summary
  "plasma-workspace 5.4.1-3-fc22 has a delay over 20 seconds upon login"
is actually an understatement for my LVDS + external monitor system:

With a "lucky boot/login", KDE starts up in 70 seconds for me, compared to 10 seconds or so with KDE 4.

When I'm unlucky (~50% chance), a boot/first login still gives me a broken KDE desktop, with symptoms exactly as described & analysed in Comment 17,

- Primary display visibly moves from LVDS to external monitor
- External monitor then shows a KDE panel on blue wallpaper but no widgets,
  and the LVDS turns black but is otherwise working

and this is after applying all recent updates, including those for KDE Plasma 5.4.2 (applied on Oct. 24).

As also described in Comment 17, the "broken desktop" case appears to be this upstream bug

  https://bugs.kde.org/show_bug.cgi?id=351079
  Spontaneously adding desktop containments at startup

Any ideas from the Fedora KDE SIG?
Comment 26 Tom Canavan 2015-12-11 23:15:05 EST
FWIW, this is still happening in Fedora 23.  I am using kf5-plasma-5.16.0-4.

Symptoms are the same as the previous comment.  It's down to a matter of luck whether plasma shows me my panel with icons and the icons on the desktop.  It has gone on for at least two minutes sometimes. After that I usually give up and reboot Sometimes everything will show up after a couple minutes, and sometimes it will not. Sometimes if I let it go long enough, things will show up little by little.  Like he said, about 50/50 chance

I am still getting the "autoStart2Done timedout, this is a BUG!"
message in /~.xsession-errors.

But I am NOT getting the
"* KActivities: FATAL ERROR: Failed to contact the activity manager daemon
* basic_code_modules.cc:70: ERROR: Module /lib64/libudev.so.1 could not be stored" error.

As far as the ~/.config/plasma-org.kde.plasma.desktop-appletsrc file, I am not getting anything added, but one line is changed each time.  It is describing the positions of icons on my desktop.  It changes even though I haven't moved anything on the desktop.  

I could post copies of this stuff, but it is rather long. 
This is a rather serious problem and costs a lot of time.  Hope this helps.
Comment 27 Tom Canavan 2015-12-12 16:03:15 EST
This problem seems to be fixed after the kde and plasma updates Sat. Dec. 12.  Login is very quick.  About 6 seconds.  I am no longer getting the  "autoStart2Done timedout, this is a BUG!" message in /~.xsession-errors.  Seems the update to 5.5 packages fixed it.  Thank you.
Comment 28 Fedora End Of Life 2016-07-19 15:57:32 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.