Hugh Brown wrote: > Jason Edgecombe wrote: >> Hugh Brown wrote: >>> Jason Edgecombe wrote: >>>> Hugh Brown wrote: >>>>> Jason Edgecombe wrote: >>>>>> hi everyone, >>>>>> >>>>>> I'm using nss_db to store more of the user account info instead of >>>>>> using >>>>>> /etc/passwd. Only the system accounts are in /etc/passwd, while the >>>>>> 1000+ user accounts are in /var/db/passwd.db. I have set >>>>>> /etc/nsswitch.conf to contain "passwd: files db" and "passwd: db >>>>>> files", >>>>>> but either way, gnome-session takes 20+ seconds to load. I can login >>>>>> normally at a text login prompt and the KDE login is fast, like <2 >>>>>> seconds. The gnome-session is fast, but only if I put the user's >>>>>> info >>>>>> into /etc/passwd. "getent passwd user >> /etc/passwd" is the command >>>>>> that I have used to do that. I'm baffled as to why gnome-session is >>>>>> not >>>>>> playing nicely with nss_db. Things are OK about a minute after >>>>>> login, >>>>>> but the gnome login is horribly slow when the user's info isn't in >>>>>> /etc/passwd. >>>>>> >>>>>> Does anyone have any insight into this problem? >>>>>> >>>>>> RedHat 5.2 Desktop, 64bit >>>>>> Dell optiplex 745 dual-core >>>>>> 2GB RAM. >>>>>> >>>>>> Sincerely, >>>>>> Jason Edgecombe >>>>>> >>>>>> >>>>> Do you have nscd running? Does login speed change if nscd is running >>>>> vs. not? >>>> I've tried nscd. login speed is the same whether it's on or off. >>>> >>>> Jason >>>> >>> I'd open a ticket with Redhat. >>> >>> Hugh >> >> I finally found some useful Logs in ~/.xsession-errors: >> >> /etc/gdm/PreSession/Default: Registering your session with utmp >> /etc/gdm/PreSession/Default: running: /usr/bin/sessreg -a -u >> /var/run/utmp -x "/var/gdm/:0.Xservers" -h "" -l ":0" "trng02" >> localuser:trng02 being added to access control list >> No profile for user 'trng02' found >> SESSION_MANAGER=local/lws10:/tmp/.ICE-unix/3522 >> Connecting to system bus failed: Did not receive a reply. Possible >> causes include: the remote application did not send a reply, the message >> bus security policy blocked the reply, the reply timeout expired, or the >> network connection was broken. >> /sbin/pam_timestamp_check must be setuid root >> Error: pam_timestamp_check is not setuid root >> Traceback (most recent call last): >> File "/usr/bin/puplet", line 467, in ? >> main() >> File "/usr/bin/puplet", line 463, in main >> p = Puplet() >> File "/usr/bin/puplet", line 82, in __init__ >> self.bus = dbus.SystemBus() >> File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 260, in >> __new__ >> return Bus.__new__(cls, Bus.TYPE_SYSTEM, use_default_mainloop, >> private) >> File "/usr/lib64/python2.4/site-packages/dbus/_dbus.py", line 99, in >> __new__ >> bus._connection = dbus_bindings.bus_get(bus_type, private) >> File "dbus_bindings.pyx", line 1692, in dbus_bindings.bus_get >> dbus_bindings.DBusException: Did not receive a reply. Possible causes >> include: the remote application did not send a reply, the message bus >> security policy blocked the reply, the reply timeout expired, or the >> network connection was broken. >> Unable to open desktop file >> file:///afs/<deleted>/trng02/linux/.gnome2/panel2.d/default/launchers/blah-003f483c8b.desktop >> >> for panel launcher: No such file or directory >> Introspect error: Did not receive a reply. Possible causes include: the >> remote application did not send a reply, the message bus security policy >> blocked the reply, the reply timeout expired, or the network connection >> was broken. >> could not attach to desktop process >> >> I think the rest of these errors were caused by me hitting >> ctrl-alt-bkspc >> > > > I'd make sure that the messagebus service is started. > e.g. > > $ service messagebus status > dbus-daemon (pid 8355) is running... > > > It also looks like gnome wants pam_timestamp_check to be setuid root. I checked and pam_timestamp_check is setuid root. ls -l shows "rwsr-xr-x root root pam_timestamp_check"
service messagebus status showed that the message bus service was running. Interestingly, the problem is still related to dbus. If I login to the console on virtual terminal 1 and run dbus-daemon --session, then run my graphical session, the login is as fast as normal. I'll play around more with dbus to see what I can find. Thanks, Jason _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
