I'm not using any particular locale (I use the default system language)
and I use a Swedish keyboard layout. The keyboard is a Logitech keyboard
connected via the PS/2 port and the mouse is a Logitech USB mouse. Also
note that this delay has not been there all the time. Even after I
upgraded to snv_b134 the login was normal. But then something happened
quite recently, I don't know what it is. The only thing I've been
tampering with in the system is the network configuration files such as
/etc/host, /etc/nsswitch.conf and /etc/inet/inodes since I was resolving
problems with slow ssh logins. I have a feeling that some configuration
file was corrupted when the system was shut down. This is just a hunch
and I may be terribly wrong. The system has always been powered off
"properly" without interruption either by the System -> shut down in
Gnome or by issuing "init 5" over ssh. What I suspect is that the "init
5" command may have interrupted something vital in Gnome corrupting the
session.
You suggested that I should add the following lines in the gnome-session
file:
#/bin/bash
truss -faldo /tmp/truss.out.$$ gnome-session --debug
I assume that you actually mean:
#/bin/bash
truss -faldo /tmp/truss.out.$$ gnome-session-real --debug
i.e. that you forgot "-real" in gnome-session. I'm currently trying this
out. When I restarted the gdm service I was immediately logged in as gdm
so I logged out and it's painfully slow. It's been 20 minutes now and
all I see is the desktop background and a little grey square in the
bottom right corner with "En" in it. The /tmp/truss file is around 11MB
so I guess I can zip it up and send it to you.
I must also warn that I'm going away tomorrow and will be unavailable
for about a week.
- Robin.
On 2010-05-11 05:11, Brian Cameron wrote:
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
opensolaris-discuss@opensolaris.org
