Re: KDE dies after login with KDM
On Fri, Nov 24, 2006 at 18:56:20 +0100, Rainer Dorsch wrote:
> Am Freitag, 24. November 2006 17:17 schrieb Florian Kulzer:
> > On Thu, Nov 23, 2006 at 17:24:28 +0100, Rainer Dorsch wrote:
> > > Hello,
> > >
> > > since a few days, I see my KDE session dying immediately after login from
> > > KDM on my etch system.
> > > I can start KDE from the console with startx without any issues.
> > > I checked /var/log/kdm and ~/.xsession-errors
> > > Nothing really meaningful in there.
[...]
> > What do you mean by "dying immediately"? After you log in, do you see
>
> Screen becomes black.
>
> > the KDE splash screen or does KDM crash before that? What happens after
>
> No, I don't see the KDE splash screen.
>
> > it dies, are you returned to the graphical log-in screen or are you
> > dropped to a terminal? Is ~/.xsession-errors completely empty after this
>
> KDM restarts
>
> > happens or not?
>
> IIRC, it is not empty, but no errors. I need to doublecheck with the next
> login.
Your first mail reminded me of a problem with KDM which I had once. Your
answers to my questions confirm that your symptoms are almost exactly
the same. In my case I could eventually identify a bug of a script in
/etc/X11/Xsession.d as the cause of the problem.
It is very easy to check which scripts in Xsession.d are run before KDM
hangs. You just have to install the package "inotify-tools" then you can
monitor access to these files. I would propose to do it like this:
Go to a terminal with CTRL + ALT + F1. Log in and tell inotify to watch
all the files in /etc/X11/Xsession.d/. It should look like this:
$ inotifywatch /etc/X11/Xsession.d/*
Establishing watches...
Finished establishing watches, now collecting statistics.
Leave inotifywatch running and return to the KDM log-in screen with CTRL
+ ALT + F7. Log in and let KDM crash and restart. Return to the terminal
with CTRL + ALT + F1 and stop inotifywatch by pressing CTRL + C. You
will get a list of all the watched files that were accessed in the
meantime. On my computer I see this for a successful log-in with KDM:
total access close_nowrite open filename
3 1 1 1 /etc/X11/Xsession.d/20x11-common_process-args
3 1 1 1 /etc/X11/Xsession.d/20xfree86-common_process-args
3 1 1 1 /etc/X11/Xsession.d/30x11-common_xresources
3 1 1 1 /etc/X11/Xsession.d/30xfree86-common_xresources
3 1 1 1 /etc/X11/Xsession.d/40xfree86-common_user-xsession
3 1 1 1 /etc/X11/Xsession.d/50x11-common_determine-startup
3 1 1 1 /etc/X11/Xsession.d/50xfree86-common_determine-startup
3 1 1 1 /etc/X11/Xsession.d/55gnome-session_gnomerc
3 1 1 1 /etc/X11/Xsession.d/60imwheel_start-imwheel
3 1 1 1 /etc/X11/Xsession.d/75dbus_dbus-launch
3 1 1 1 /etc/X11/Xsession.d/80im-switch
3 1 1 1 /etc/X11/Xsession.d/90gpg-agent
3 1 1 1 /etc/X11/Xsession.d/90im-switch
3 1 1 1 /etc/X11/Xsession.d/90x11-common_ssh-agent
3 1 1 1 /etc/X11/Xsession.d/90xfree86-common_ssh-agent
3 1 1 1 /etc/X11/Xsession.d/92xprint-xpserverlist
3 1 1 1 /etc/X11/Xsession.d/99x11-common_start
This list will tell you how far the system got before KDM was restarted.
The last script that was accessed should be the one that causes your
problem. If no Xsession.d scripts were accessed at all then we have to
look for issues earlier in the KDM log-in process. In any case this
should help to narrow down the list of suspects.
--
Regards,
Florian
Reply to: