Robin:
On 05/ 8/10 02:14 PM, Robin Axelsson wrote:
The delay is 3 minutes long (~180 seconds) and not 2 or 30 seconds. This is delay easy to measure since there's a clock in the bottom right corner of the login splash that is frozen which "jumps" 3 minutes forward when the input text field for the user login pops up. I supply a picture of what the login soplash screen looks like when it's frozen and another /var/adm/messages logfile that is linked to this image and contains more "before and after" information.
Looking at the messages20100508-1959.log.txt file that you provided, I notice the following: - The GDM service started at 19:59:27 - At 19:59:33 it looks like the slave daemon informs the greeter to prompt for the username - At 20:06:14 it looks like the prompt was answered with a username. This looks like a 6 minute delay, much longer than 3 minutes, but perhaps it took you some additional time to actually enter a username? Unfortunately, the syslog doesn't seem to contain any information between 19:59:33 and 20:06:14 to indicate what might be causing this hang. Later in the log, I also notice that GDM service started at 20:08:21 and that the greeter was informed to prompt for a username at 20:08:31, but that is where the log ends, so I don't see any delay here. Also the 0-greeter*log files (which shows stdout/stderr when the greeter is running) shows the same warning/error messages that I see on my machine but I do not have a slowdown. So this log does not seem to highlight anything unusual that is causing the hang for you. Since this problem seems to only be affecting a few people, I wonder if you might be able to identify what about your setup might be different that could be causing the slowdown. Are you using a particular locale, IM (Input Method) setup, or somesuch that might be causing GDM to behave differently for you than for others? If you are using a locale, then does GDM not hang if you switch to using the default C locale? I notice that bug #14857 in defect.opensolaris.org seems like it might be related. I notice the same unusual GConf error in the "out" file that you provided. Your problem sounds different than bug #14857 since it seems to be affecting you on the login screen, while the slowdown in bug #14857 seems to affect the user session starting. However, if this is a locale issue, then this might be explained if you are setting your default locale systemwide (so GDM picks it up) while the person who reported bug #14857 might be setting their locale via the GDM login screen. http://defect.opensolaris.org/bz/show_bug.cgi?id=14857 It might be helpful to get some truss output to debug this problem. If you rename /usr/bin/gnome-session to /usr/bin/gnome-session-real and then create a script (with execute permissions) named /usr/bin/gnome-session which contains these two lines #/bin/bash truss -faldo /tmp/truss.out.$$ gnome-session --debug Then restart the "gdm" service. This will cause GDM to run the script to start gnome-session, which will launch the gnome-session-real with truss turned on. This will do two things. It will make things even slower, and it will create a /tmp/truss.out.(pid) file which will show what gnome-session is doing, and might highlight the problem. The truss output timestamps each line so it might better highlight where the problem is happening. Truss output is large, so it might make sense to attach the output to doo bug #14857 rather than as an email attachment. > I forgot to say: I don't know what "face browser" means. If it is the > feature that enables the possibility of "choosing" users at the login > and/or poweroff/restart the the answer to this question is no. Yes, that is what I meant. If you don't have the Face Browser enabled, then there is no need to load the users. However, according to the syslog, this slowdown is only a couple of seconds, and probably not the issue which is causing the long slowdown that you are seeing. --- Brian _______________________________________________ opensolaris-discuss mailing list [email protected]
