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.
- Robin.
On 2010-05-07 18:34, Brian Cameron wrote:
Robin:
According to the GDM debug output from /var/adm/messages that you
provided the login program is taking 13 seconds to start up. This
does not seem an unusually long time for GDM to start up.
Also I do not see anything in the log which indicates that anything in
particular which is very slow. There is a 3 second delay from 10:46:35
to 10:46:38 where gnome-session is starting for the login GUI (this
is normal) and a 2 second delay loading users from 10:46:42 to 10:46:44.
Do you have the face browser enabled in GDM or does it just ask you to
enter the username via the keyboard when it starts up? If you do not
have the face browser enabled, then it should not bother loading
users. If you do not have the face browser enabled, then this might be
a bug and an opportunity to speed GDM by perhaps 2 seconds. Though if
you do have the face browser enabled, this is a normal delay.
The error messages in the 0-greeter.log.txt file you provided are normal
and do not indicate anything in particular that looks like it would make
GDM have poor performance.
Note that since OpenSolaris 09.06 the new GDM rewrite is used. The
new GDM is a bit slower than the old GDM 2.20 which was delivered in
older versions of OpenSolaris. The new GDM is a bit slower because it
loads more GNOME infrastructure when showing the login GUI (e.g.
metacity, gnome-settings-daemon, gnome-session). While it is a bit
slower, the new GDM has much better a11y support due to sharing more of
the same infrastructure that the normal GNOME user sessions use.
I am sure there are opportunities to speed up the login screen, and
this is something we (and the upstream GDM community) are always
working to improve. Unfortunately I don't see anything obvious that
indicates a performance problem with the data that you provided, though.
One additional thing you can check. If you are seeing a 30 second delay
which isn't showing up in the logs, then I wonder if some program
started by gnome-session used with the login screen might be crashing.
If a program started by gnome-session crashes it will cause a delay and
would not show up in the GDM debug syslog output.
Normally core files are not generated by gdm system processes, but if
you configure coreadm like this:
global core file pattern: /var/tmp/core-%f.%p
global core file content: all
init core file pattern: core
init core file content: default
global core dumps: enabled
per-process core dumps: enabled
global setid core dumps: enabled
per-process setid core dumps: enabled
global core dump logging: disabled
Then gdm processes will generate core files in /var/tmp named
"core-(program)-(pid)". Refer to the coreadm man page to learn how
to configure coreadm as shown above. Once configured, then you can
restart the login screen. If you see any core files in /var/tmp after
you login when the performance is bad, then this would be an indication
that this might be the problem.
Brian
Oh, I forgot the other logs (the clock at the bottom right in the login
splash screen is frozen at 10:46 and jumps to 10:49 when the input text
field for username pops up).
I saw some complaints about missing files (module xtsol and fbdev
missing) in the Xorg log but otherwise it looks ok. But I don't know
much about Gnome and GDM so I'm note really at liberty to say.
The :0.log and the :0-greeter.log files found in /var/log/gdm showed
some errors which I believe is relevant but I'm unable to yield a proper
interpretation and fix the problem. They were easy to locate by looking
at the time stamps.
I attach them with this message.
- Robin.
On 2010-05-06 19:20, Brian Cameron wrote:
To debug this, I would recommend editing the /etc/gdm/custom.conf file
and add the line "Enable=true" after the line that says "[debug]" so
it looks like this:
[debug]
Enable=true
Then reboot. After reboot, the syslog file (/var/adm/messages) should
have GDM related debug messages near the bottom. Each has a timestamp.
Using these timestamps, you should be able to determine if the slowdown
is happening before the GDM is launched, or if the slowdown is
happening
because GDM itself is doing something slow. You can share the relevant
gdm-related debug from the bottom of your syslog with us and we can
help
with diagnosing it if the it isn't clear what the problem might be.
Also, it might be worth checking the GDM log files in /var/log/gdm.
The files in this directory are saved per-display (have the $DISPLAY
value in the filename) and they contain debug logs from the GDM slave
daemon and the GUI greeter for each display. If the slowdown is
happening as these programs are launched, then there might be some
useful error messages here.
You might also check your Xorg logs in /var/log and make sure that
there
is nothing indicating that the Xserver might be slow in starting up for
some reason.
Brian
On 05/ 6/10 08:11 AM, Robin Axelsson wrote:
I see one error message complaining about failure to start service:
"svc:/network/sendmail-client:default"
When looking at the list of running services ("~$ svcs") this
service is
the only one in maintenance mode, all other services are online except
for the "legacy-run" services. When checking the log of this
service it
says:
-------------------
[ May 6 14:56:07 Enabled. ]
[ May 6 14:56:29 Executing start method
("/lib/svc/method/sendmail-client start"). ]
[ May 6 14:56:30 Method "start" exited with status 0. ]
[ May 6 14:56:35 Stopping because all processes in service exited. ]
[ May 6 14:56:35 Executing stop method
("/lib/svc/method/sendmail-client
stop 85"). ]
[ May 6 14:56:35 Method "stop" exited with status 0. ]
[ May 6 14:56:35 Executing start method
("/lib/svc/method/sendmail-client start"). ]
[ May 6 14:56:35 Method "start" exited with status 0. ]
[ May 6 14:56:35 Stopping because all processes in service exited. ]
[ May 6 14:56:35 Executing stop method
("/lib/svc/method/sendmail-client
stop 95"). ]
[ May 6 14:56:35 Method "stop" exited with status 0. ]
[ May 6 14:56:35 Executing start method
("/lib/svc/method/sendmail-client start"). ]
[ May 6 14:56:35 Method "start" exited with status 0. ]
[ May 6 14:56:35 Stopping because all processes in service exited. ]
[ May 6 14:56:35 Executing stop method
("/lib/svc/method/sendmail-client
stop 97"). ]
[ May 6 14:56:35 Method "stop" exited with status 0. ]
[ May 6 14:56:35 Executing start method
("/lib/svc/method/sendmail-client start"). ]
[ May 6 14:56:35 Method "start" exited with status 0. ]
[ May 6 14:56:35 Stopping because all processes in service exited. ]
[ May 6 14:56:35 Executing stop method
("/lib/svc/method/sendmail-client
stop 99"). ]
[ May 6 14:56:35 Method "stop" exited with status 0. ]
[ May 6 14:56:35 Restarting too quickly, changing state to
maintenance. ]
[ May 6 14:59:11 Leaving maintenance because disable requested. ]
-------------------
But I doubt that this service is the culprit that causes the delay in
the GDM splash login screen.
- Robin.
On 2010-05-06 14:45, Matthias Pfützner wrote:
What can you see on the screen, once you hit the<escape> key after
the
first
moving splash part shows? That'll finish the splash,and you'll see
the
console...
Matthias
You (Robin Axelsson) wrote:
Quite recently the system have picked up a new behaviour that occurs
every time I boot and every time I log out and back in again; when
the splash login screen appears it takes about 3 minutes before it
prompts for username. In the meantime it responds to CIFS and ssh.
What's wrong and how can I troubleshoot this?
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
--
Matthias Pfützner | mailto:pfu...@germany | Kunde versenkt, Geld
@work: +49 6103 752-394 | @home: +49 6151 75717 | schwimmt oben...
;-)
SunCS, Ampèrestraße 6 | Lichtenbergstraße 73 |
63225 Langen, FRG | 64289 Darmstadt, FRG | Herbert Kuhlmann
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
.
.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
