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
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
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
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
Created attachment 1080595 [details] .xsession-errors when the hang occurs
Created attachment 1080596 [details] .xsession-errors where there is no hang
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
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
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.
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.
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.
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.
It looks like kde frameworks 5.15 (and also kf5-kservice 5.15.0-1.fc22) fixed the problem for me. Could anyone confirm?
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}
(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
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.
(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.
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.
Created attachment 1085136 [details] Snapshot of .config/plasma-org.kde.plasma.desktop-appletsrc when desktop was good
Created attachment 1085137 [details] Snapshot of .config/plasma-org.kde.plasma.desktop-appletsrc when widgets were not showing
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.
Created attachment 1085140 [details] ~/.xsession-errors for first login after boot, with full debug output, including timing info
Created attachment 1085143 [details] ~/.xsession-errors for first login after boot, filtered to only show kwin_core & kscreen
(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.
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.
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?
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.
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.
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.