|
Bugzilla – Full Text Bug Listing |
| Summary: | Long delay after entering username at login box | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 13.1 | Reporter: | malcolm moore <st-malcolm.moore> |
| Component: | Basesystem | Assignee: | Forgotten User sLJ7K2dvxj <forgotten_sLJ7K2dvxj> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | forgotten_sLJ7K2dvxj, lchiquitto, nfbrown |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | openSUSE 13.1 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | /var/log/messages | ||
|
Description
malcolm moore
2013-11-25 08:52:06 UTC
*** Bug 851612 has been marked as a duplicate of this bug. *** Leonardo, any ideas? As a non programmer .... so I may be talking rubbish If you time the login from 12.3 in our environment. It takes about 30 seconds from the start of entering your password to getting a working KDE desktop from a cold boot The entering the username and password bit is almost instant and then you get the KDE splash and then a few seconds pause before the green kickoff button works If you do the same for 13.3 it also takes about 30 seconds from the start of entering your password to a working KDE desktop There is a 15 second pause after entering your username before you can type a password but once it's going the desktop is usable almost immediately after the KDE splash has finished. I looks to me as if you are mounting the home directory as soon as you have entered the username where as before you mount it after the login box has finished This gives you roughly the same time to start up but the pause is in the wrong place. Users will wait 15 seconds after they have logged in ( since they are used to Windows taking an age at that point anyway ) but they won't want to wait 15 seconds between entering a username and a password With both the second login is much quicker as the home directory is generally still there I would like to set this as 'critical' as it really isn't usable the way it is but I figured people would moan at me since it does work it's just horrible Doesn't look like an AutoFS problem, unless mounting the volume is taking more time than it should, perhaps. Some questions for you: - Does the delay happen only when logging in on KDE? Are you using kdm? - What about logging in on the console, what's the behavior? Any delays? If it's really AutoFS taking too long to mount the home dir, could you please set DEFAULT_LOGGING to "debug" in /etc/sysconfig/autofs, reboot, reproduce the problem and then send us the logs from /var/log/messages? Thanks. Yes we are using kdm I will do the other stuff Monday Should it mount the home directory as soon as you enter the username and before you enter the password ? I don't know, but if kdm attempts to access any file in the user's home directory before asking for the password, it will trigger the mount. Created attachment 569797 [details]
/var/log/messages
2013-12-02T09:24:21.364660+00:00 test131 dhcpcd[1571]: enp3s0: exiting
2013-12-02T09:24:37.137221+00:00 test131 automount[2709]: handle_packet: type = 3
???
Mal
I don't know if this is significant - see the 'Client' section https://wiki.archlinux.org/index.php/NFS The time is remarkable suspicious This is the salient bit from the ArchLinux howto Clients need nfs-utils to connect, and to avoid an approx 15 seconds delay with an accompanying error in dmsg that reads, "RPC: AUTH_GSS upcall timed out," users will need to start rpc-gssd service on any client. As I get a 15 second delay then:- RPC: AUTH_GSS upcall timed out, Please check the user daemon is running Workaround Blacklist rpcsec_gss_krb5 Neil, any idea about this one? I believe this is address by commit f8747e649c590da42c92f458f9ec03d41ad1a0bb in our 13.1 kernel tree, dated 18-Nov-2013. So it should be fixed with the recent kernel update kernel-XXX-3.11.10-7.1. Malcolm, does the kernel update fix it (if you disable the workaround)? Will check Monday and let you know M Seems OK. I will close this bug Many thanks M |