?

Log in

No account? Create an account
entries friends calendar profile My Website Previous Previous Next Next
Mark Atwood
fallenpegasus
fallenpegasus
Dear LazyWeb. Very slow login into my FC6 Desktop
I recently upgraded my laptop from FC5 to FC6.

When I graphically login to my account, the login process hangs on a blank grey screen for a couple of minutes, and then proceeds to login normally. If I create a new user account, when I login to it, here is no hang.

It smells like a network or name resolver timeout. I think it's the WM, Metacity, that is hanging. I suspect there is something present or absent in my gconf configuration that's causing it. Howeve, the Gnome people have copied one of Windows bad features, in that the login process and WM and Desktop initialization process is not logged or recorded anywhere.

Anyone else seen this? Is there a simple, or even complex, way to find out whats happening and fix it?

And "just create a new account and use it" isn't an answer.

Clues?

Tags: , ,
Current Location: Home, Capitol Hill, Seattle WA
Current Mood: annoyed annoyed

5 comments or Leave a comment
Comments
mauser From: mauser Date: July 4th, 2007 02:16 am (UTC) (Link)
Create the new account and compare the settings to see what's different?
zanfur From: zanfur Date: July 4th, 2007 03:05 am (UTC) (Link)
I've had to do this. It was a resolver timeout in my case (took me a very long tom e to find it, though). Quicker solution is this: Rename your home directory, and recreate it as a copy of /etc/skel with all files owned by you (include the dotfiles). Then copy the data files you want in you home directory, spend some time configuring things again, and call it good.

If you want to actually track down the problem, you could plunk around in your dotfile directories (.gconf, mainly, but .gnome, .gnome2, .gconfd, .gnome2_private, .mcop, .metacity, .update-manager, .update-notifier, and .gnomerc are also likely candidates). Look at everything the session manager starts (it's in the menus somewhere).

As for logging, you *can* see those logs. The file you probably want is in your home directory, named ".xsession-errors". It's not logged via syslog (would you want everyone to be able to see exactly what you're running?), so /etc/X11/Xsession (called by gdm) execs itself with stdout and stderr set to $HOME/.xsession-errors. All spawned processes inherit this, unless they explicity close their file descriptors.

You can also bump up the logging level of gdm up by adding "Enable=true" to the "[debug]" section of gdm.conf, but that's not usually useful unless gdm itself is causing the delay.

Of course, if you want to know exactly what processes are being spawned when you log in, even if Xsession doesn't log it, turn on sa ("accton on") and check the logs.
fallenpegasus From: fallenpegasus Date: July 4th, 2007 09:57 pm (UTC) (Link)
Thanks for the .xsession-errors hint.

It looks like it was puplet, which is Fedora's brain dead "There are updated packages to install" taskbar applet. I had already uninstalled the "automatically query the rpm archives" daemon. When puplet starts, it tries to talk to that local daemon, and it tries to talk to one of the RPM archives, the one at Duke. Making queries across the internet at login time doesnt work so well on a FC6 laptop, since the network is managed by NetworkManager and nm-applet, which don't bring up the network until the user actually gets logged in (because it has to ask the user for permission to decrypt the keyring where the wireless keys are kept.)

And Puplet freezes the login and doesnt let anything else proceed until it times out trying to find them.

I consider this three different bugs in puplet. That it depends on the local rpm daemon, that it depends on internet access, and most of all, that it thinks that checking for updates should freeze the login, instead of idly running in the deep background.
fallenpegasus From: fallenpegasus Date: July 4th, 2007 11:13 pm (UTC) (Link)
There were actually two problems. One was the puplet problem, and the other was that somehow the upgrade process had put metacity in the .gnome2/session data twice.

So Metacity was trying to start twice, arguing with itself, and playing "try and timeout, try something else and timeout some more" with itself when taking the WM authority with X and Gnome. And doing so also would hose the .metacity/sessions/foobar session file, which also would cause metacity to search and timeout looking for other places to get it's session startup data.

Preferences > More Preferences > Sessions and then carefully looking at it and the .gnome2/sessions file found it.

Thanks again for the pointers.
zanfur From: zanfur Date: July 5th, 2007 03:34 am (UTC) (Link)
Huh. I haven't seen that particular problem before. Glad you found it, though!
5 comments or Leave a comment