Re: [opensuse-factory] logon timings - 32 secs from login to working desktop
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
On Tuesday 02 Jun 2015 14:39:41 Knurpht - Gertjan Lettink wrote: 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? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Dienstag, 2. Juni 2015 schrieb ianseeks:
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
Signal 11 means segfault, and the second log message also explicitely mentions "segfault". The interesting question is why it is crashing ;-) Can you reproduce the segfault by manually trying to start /usr/bin/kactivitymanagerd ? (BTW: Is it running after login? I doubt, but please check nevertheless.) Maybe your ~/.xsession-errors also contains some hints about the segfaults. Regards, Christian Boltz -- [Fontlinge] Glücklich wirst du damit nicht werden. Die Windowsversion konnte das, denn ich war jung und dumm, brauchte das Geld und dachte, man könne sich auf Standards verlassen. Die Sortierung nach PanoseID ergab dann das maximale Durcheinander. :-( [Ratti] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 03 Jun 2015 00:15:56 Christian Boltz wrote:
Hello,
Am Dienstag, 2. Juni 2015 schrieb ianseeks:
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
Signal 11 means segfault, and the second log message also explicitely mentions "segfault".
The interesting question is why it is crashing ;-)
Can you reproduce the segfault by manually trying to start /usr/bin/kactivitymanagerd ? (BTW: Is it running after login? I doubt, but please check nevertheless.) it does seem to be running on this login session, it didn't segfault this time.
Maybe your ~/.xsession-errors also contains some hints about the segfaults. xsession-errors doesn't seem very helpful unless you know what you are looking for, you can't link lines in this file to the journal to see an order of events as the lines in ~/.xsession-errors-:0 do not have any time stamp what soever. I do get lots of lines like this "Battery No file queue: suspended or on battery" even though i'm on a tower machine.
Why is ~/.xsession-errors a zero length file but ~/.xsession-errors-:0 is the file that contains the log, i would have thought it would be the other way round and the ~/.xsession-errors-:0 file becomes the log containing the data from the previous session.
Regards,
Christian Boltz
thanks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-06-03 10:35, ianseeks wrote:
Why is ~/.xsession-errors a zero length file but ~/.xsession-errors-:0 is the file that contains the log, i would have thought it would be the other way round and the ~/.xsession-errors-:0 file becomes the log containing the data from the previous session.
No, the previous session should be in .xsession-errors.old The :0 refers to the "display", I think. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wednesday 03 Jun 2015 12:46:30 Carlos E. R. wrote:
On 2015-06-03 10:35, ianseeks wrote:
Why is ~/.xsession-errors a zero length file but ~/.xsession-errors-:0 is the file that contains the log, i would have thought it would be the other way round and the ~/.xsession-errors-:0 file becomes the log containing the data from the previous session.
No, the previous session should be in .xsession-errors.old
that would make sense but i don't have one of those, i don't have any previous xsession data
The :0 refers to the "display", I think.
thanks. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On Wednesday 03 Jun 2015 09:47:47 Knurpht - Gertjan Lettink wrote:
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.
I don't know of any reason why SDDM is better or worse than KDM so i've not even attempted to convert to SDDM. It stayed as KDM when i did the upgrade. I'll try the tests on a first login after a reboot and see if that still happens thanks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Knurpht - Gertjan Lettink
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.
Last trials and conversation here indicate sddm is broken, not releasing and not stopping plymouthd to allow reaching graphical target. sddm *should* not be recommended for use. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 3. Juni 2015, 07:10:57 schrieb Patrick Shanahan:
Last trials and conversation here indicate sddm is broken, not releasing and not stopping plymouthd to allow reaching graphical target. sddm *should* not be recommended for use.
Wrong. sddm only was "broken" when you enabled it with "systemctl enable sddm.service". If you use the standard display-manager.service and configure sddm in /etc/sysconfig/displaymanager, it should work fine. Anyway, that problem should be fixed with the latest Tumbleweed snapshot: - Add sddm-service-handle-plymouth.patch -- sddm has some rudimentary support for plymouth handling, which only works with plymouth-quit.service (the servce is not enabled on openSUSE). For users of sddm.service, we need to issue plymouth quit command by hand in this case It's of course your decision whether you use sddm or keep using kdm (or any other like lightdm for that matter) though. Both should in fact work fine. sddm still lacks features compared to kdm, like e.g. remote login. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Wolfgang Bauer
Am Mittwoch, 3. Juni 2015, 07:10:57 schrieb Patrick Shanahan:
Last trials and conversation here indicate sddm is broken, not releasing and not stopping plymouthd to allow reaching graphical target. sddm *should* not be recommended for use.
Wrong. sddm only was "broken" when you enabled it with "systemctl enable sddm.service". If you use the standard display-manager.service and configure sddm in /etc/sysconfig/displaymanager, it should work fine.
Anyway, that problem should be fixed with the latest Tumbleweed snapshot: - Add sddm-service-handle-plymouth.patch -- sddm has some rudimentary support for plymouth handling, which only works with plymouth-quit.service (the servce is not enabled on openSUSE). For users of sddm.service, we need to issue plymouth quit command by hand in this case
It's of course your decision whether you use sddm or keep using kdm (or any other like lightdm for that matter) though. Both should in fact work fine. sddm still lacks features compared to kdm, like e.g. remote login.
Tks for notice, but I still have a problem with it. Of 5 machines my main desktop was the only working with sddm, installed as you describe. The latest update borked that and I had to change /etc/sysconfig/displaymanager from sddm to kdm{xdm,...} or I had only the "green screen" and no login. But the plymouthd instance present in earlier trials on other machines was not there :). I still feel too many "rough" edges to sddm for recommendation to "regular" users. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 4. Juni 2015, 07:56:52 schrieb Patrick Shanahan:
The latest update borked that and I had to change > /etc/sysconfig/displaymanager from sddm to kdm{xdm,...} or I had only the "green screen" and no login.
Hm. It (still) works fine here, but I'm running 13.2 with sddm from KDE:Frameworks5 (the devel repo for Factory/Tumbleweed).
But the plymouthd instance present in earlier trials on other machines was not there :).
Then plymouth probably is not the reason, at least not directly. Does disabling plymouth fix it? (plymouth.enable=0 on the kernel command line) Or maybe try to switch to a different theme. Try to set e.g. "Current=elarun" in the "[Theme]" section in /etc/sddm.conf. I did have similar problems with the "breeze" theme when not all components were found because I installed them to wrong directories in my packages.
I still feel too many "rough" edges to sddm for recommendation to "regular" users.
Well, it should work. There are no "rough edges" in my experience, except that in 13.2 the X session hangs on exit when gnome-keyring-pam is installed (this should be fixed with the gnome-keyring version in Tumbleweed though). One problem I am aware of ATM is that a GNOME session does not start: https://bugzilla.opensuse.org/show_bug.cgi?id=931314 But sddm is only used as default for a KDE installation. And again, it still lacks features compared to kdm. Most "regular" users probably won't even notice though I suppose. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 04 Jun 2015 14:10:55 Wolfgang Bauer wrote:
Am Donnerstag, 4. Juni 2015, 07:56:52 schrieb Patrick Shanahan:
The latest update borked that and I had to change >
/etc/sysconfig/displaymanager
from sddm to kdm{xdm,...} or I had only the "green screen" and no login.
Hm. It (still) works fine here, but I'm running 13.2 with sddm from KDE:Frameworks5 (the devel repo for Factory/Tumbleweed).
But the plymouthd instance present in earlier trials on other machines was not there :).
Then plymouth probably is not the reason, at least not directly. Does disabling plymouth fix it? (plymouth.enable=0 on the kernel command line)
Or maybe try to switch to a different theme. Try to set e.g. "Current=elarun" in the "[Theme]" section in /etc/sddm.conf.
I did have similar problems with the "breeze" theme when not all components were found because I installed them to wrong directories in my packages.
I still feel too many "rough" edges to sddm for recommendation to "regular" users.
Well, it should work. There are no "rough edges" in my experience, except that in 13.2 the X session hangs on exit when gnome-keyring-pam is installed (this should be fixed with the gnome-keyring version in Tumbleweed though).
One problem I am aware of ATM is that a GNOME session does not start: https://bugzilla.opensuse.org/show_bug.cgi?id=931314 But sddm is only used as default for a KDE installation.
And again, it still lacks features compared to kdm. Most "regular" users probably won't even notice though I suppose. The regular users are generally quiet, its the others that shout the loudest when features are missing. Is there a list of "missing" features? the one i've heard of is not being able to easily select/deselect users to be displayed at logon.
Kind Regards, Wolfgang
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 4. Juni 2015, 14:05:16 schrieb ianseeks:
The regular users are generally quiet, its the others that shout the loudest when features are missing. Hm? I meant that "regular" users probably won't need most of the missing features. And on a default installation, the login screen is not even visible because Auto-Login is enabled.
It all depends on how you define a "regular" user though of course...
Is there a list of "missing" features?
I am not aware of one. It's definitely not planned to implement every single "feature" of kdm, and it probably doesn't make sense (or maybe is not even possible) either. sddm is a totally independent product (written from scratch not too long ago), and has absolutely nothing to do with kdm. There is a TODO list though: https://github.com/sddm/sddm/wiki/TODO
the one i've heard of is not being able to easily select/deselect users to be displayed at logon.
You can to a certain degree: - you can specify a range of user ids to be shown (this setting is available in the config module, but saving the setting doesn't work at the moment) - you can hide specific users by listing them in the config file It is not possible at the moment to explicitely configure specific users (outside the specified range) to be _shown_. But AccountsService support (as listed on the TODO page) would "fix" that. AccountsService allows to configure for each user separately whether it should be shown or not, it is also used by gdm and lightdm btw. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (6)
-
Carlos E. R. -
Christian Boltz -
ianseeks -
Knurpht - Gertjan Lettink -
Patrick Shanahan -
Wolfgang Bauer