Op dinsdag 2 juni 2015 18:20:18 schreef ianseeks:
On Tuesday 02 Jun 2015 14:39:41 Knurpht - Gertjan Lettink wrote:
Op maandag 1 juni 2015 10:02:42 schreef ianseeks:
hi
I've got 4 logins on one machine i use for differing activities and one of them operates slightly different as to how it gets from login to desktop. All 4 take the same time of 32 seconds to get to a working desktop.
This is about the progress bar on the splash screen, three of the logins take 4-5 seconds to get to 85%, then 23-24 seconds to get to 100% and a further 4 seconds to get to the desktop. The strange one takes 4 seconds to get to 100% and then a further 28 seconds to get to a working desktop.
Is there anywhere i can look to see why this one should be different to the other 3?
regards
Ian
What you can do is use 'journalctl -xn 600', then use the spacebar to browse it. You'll find completion of the boot process and some line about sddm-helper adding a cookie for the user that logs in. AFAIK that's where the user's desktop session starts. That will give you a starting point, now browse through the file, look for the kwallet migration agent as a point where the desktop has started. The info provided by journalctl should also give some insight on possible delays.
Thanks. I'm using kdm so i can't see sddm-helper. This journal log doesn't make much sense to me. I checked for "kdm" starting, then followed loading of lots of kglobalaccel until about the 4 secs marker (slashscreen progress bar getting to 85%) then rtkit-daemon kicks in followed by continuing to shutting down the previously logged in user, more loading of kglobalaccel until the timing indicates the progress bar is at 100% but there is no more logging of the final 4 seconds of getting to the desktop. There don't seem to be any errors. The only thing to show a gap in logging for 19 seconds (progress bar at 85%) is just after systemd stopping a user-xxxx slice (the previous logged in user) and then the kernel QXcbEventReader logs the following : Jun 02 14:32:35 LinuxMachine QXcbEventReader[7889]: <audit-1701> auid=1004 uid=1004 gid=100 ses=18 pid=7889 comm="QXcbEventReader" exe="/usr/bin/kactivitymanagerd" sig=11 Jun 02 14:32:35 LinuxMachine kernel: QXcbEventReader[7889]: segfault at 7fde85ed3c69 ip 00007fde85ed3c69 sp 00007fde8397fe60 error 14 in icudt55l.dat[7fde8615e000+18b6000] Jun 02 14:32:35 LinuxMachine kernel: audit: type=1701 audit(1433251955.534:2724): auid=1004 uid=1004 gid=100 ses=18 pid=7889 comm="QXcbEventReader" exe="/usr/bin/kactivitymanagerd" sig=11
then it carries on with loading kglobalaccel.
The journal doesn't even show me starting up kmail
Does that make any sense to you?
Is there any reason you're using kdm instead of sddm (the new default)? Could it be the desktop tries to restore a previous session that contains (now) invalid entries? Try setting it to start with an empty session. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org