Just to report what I did last night. I did a relogin with truss on
gnome-session-real (since the /usr/bin/gnome-session was renamed to
gnome-session-real). The system froze and was stuck as I described in my
previous post. After waiting for about 2 hours I interrupted my attempt.
The truss file reached 20MB when I interrupted the operation. I will
retry this once I get confirmation that the change I did in
"/usr/bin/gnome-session" is correct and how long it should take.
I also tried without my correction. I rebooted the system and all I saw
was a black screen with a busy pointer. When logging in I saw that the
truss files in the /tmp/ dir were literaly exploding in size. Initially
they were 600MB in size and reached over a gig within a few minutes so I
stopped this before things would go haywire.
I would also like to know how long time this trussing is supposed to
take. I understand that patience is a virtue but it's too much for me to
babysit the computer for 12 hours waiting for the login screen to appear.
I will return in 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
