can anyone think of any reason why on one of my systems I can't login with lightdm? as soon as I do (with any account, including a brand new one without any weird/old/obsolete dotfiles), it seems to login OK but then logs out again immediately. my normal desktop environment is xfce, but the same thing happens if i tell lightdm to use lxde or gnome or anything else. logging in on a text VT and running startx works perfectly, and is how i've had to login for the last few months. I have four other very similar systems where lightdm works without a problem, including a mythtv box set to auto-login as the mythtv user. two of them are sysvinit, two of them are systemd. i can't see anything in the logs to indicate any problem, even the auth.log just shows that the session was started and then the session terminated immediately afterwards. any hints on what to look for in the logs or where/how to increase debug log levels would also be appreciated. craig -- craig sanders <cas@taz.net.au>
Have you tried another dm? XDM or KDM for example? Does it crash X or just return to a login prompt without restarting X? Daniel. On 29/03/15 13:46, Craig Sanders wrote:
can anyone think of any reason why on one of my systems I can't login with lightdm? as soon as I do (with any account, including a brand new one without any weird/old/obsolete dotfiles), it seems to login OK but then logs out again immediately.
my normal desktop environment is xfce, but the same thing happens if i tell lightdm to use lxde or gnome or anything else.
logging in on a text VT and running startx works perfectly, and is how i've had to login for the last few months.
I have four other very similar systems where lightdm works without a problem, including a mythtv box set to auto-login as the mythtv user. two of them are sysvinit, two of them are systemd.
i can't see anything in the logs to indicate any problem, even the auth.log just shows that the session was started and then the session terminated immediately afterwards. any hints on what to look for in the logs or where/how to increase debug log levels would also be appreciated.
craig
On Sun, Mar 29, 2015 at 02:07:52PM +1100, Daniel Jitnah wrote:
Have you tried another dm? XDM or KDM for example?
nope, and I don't really want to. lightdm works on my other boxes, it should work on this one too. It used to work until a few months ago. i'm assuming that there's something weird in my pam or whatever config which is causing this - this particular machine has been upgraded for years and even though all the hardware has been replaced many times, IIRC it has never been rebuilt from scratch since i first installed debian on it in 1994. so there's bound to be lots of weird old cruft in /etc one of the other machines is almost as old, the others are relatively new (a few years and a few weeks old respectively).
Does it crash X or just return to a login prompt without restarting X?
no crash, it just returns to the X login screen. craig -- craig sanders <cas@taz.net.au> BOFH excuse #105: UPS interrupted the server's power
On Sun, Mar 29, 2015 at 02:22:57PM +1100, Craig Sanders wrote:
On Sun, Mar 29, 2015 at 02:07:52PM +1100, Daniel Jitnah wrote:
Have you tried another dm? XDM or KDM for example?
nope, and I don't really want to. lightdm works on my other boxes, it should work on this one too. It used to work until a few months ago.
FYI, I tried KDM yesterday. same problem, so it's not specific to lightdm.
i'm assuming that there's something weird in my pam or whatever config which is causing this - this particular machine has been upgraded for
i've tried temporarily disabling the non-essential pam modules (pam_tmpdir, pam_ssh, pam_ck_connector) and that makes no difference either, so probably isn't my pam config.
Does it crash X or just return to a login prompt without restarting X?
no crash, it just returns to the X login screen.
and still no hint in any log files as to what the problem might be. google says it's not an entirely uncommon problem, with various causes (mostly permissions on certain directories or files) but none of the solutions that people were talking about were at all relevant. fortunately, logging in on a tty and running startx works perfectly. craig -- craig sanders <cas@taz.net.au>
On Sun, 29 Mar 2015 at 13:46 Craig Sanders <cas@taz.net.au> wrote:
can anyone think of any reason why on one of my systems I can't login with lightdm? as soon as I do (with any account, including a brand new one without any weird/old/obsolete dotfiles), it seems to login OK but then logs out again immediately.
Sounds like the xsession is dying. In typical fashion, errors will most likely get logged to $HOME/.xsession-errors, but not shown to the user. I not entirely sure how lightdm works, but try looking in $HOME/.xsession-errors after a dud login, and see if that helps. Note this file will get overwritten if you login successfully, so you may have to use use a text mode console, or login as another user then sudo to root to access it.
On Sun, Mar 29, 2015 at 10:27:50PM +0000, Brian May wrote:
Sounds like the xsession is dying. In typical fashion, errors will most likely get logged to $HOME/.xsession-errors, but not shown to the user.
yep, looked there. no sign of any problem. i've also tried enabling the debugs option on various pam modules, but they seem OK...as you suggest, i'm pretty sure it's not an auth or login problem, but a session problem after login. i was kind of hoping that someone would know something really obvious and stupid about X / lightdm / x sessions / xfce / whatever that i didn't. no such luck.
Note this file will get overwritten if you login successfully, so you may have to use use a text mode console, or login as another user then sudo to root to access it.
as you say, it does get overwritten, and i did roughly what you suggested. no luck. craig -- craig sanders <cas@taz.net.au>
On Mon, Mar 30, 2015 at 10:47:26AM +1100, Trent W. Buck wrote:
Do the symptoms present if you create a new user & log in as it?
yep, happens on any login, even freshly created ones. so it's not my login's dotfiles. that was one of the first things i thought of. craig -- craig sanders <cas@taz.net.au>
On 30/03/15 09:44, Craig Sanders wrote:
On Sun, Mar 29, 2015 at 10:27:50PM +0000, Brian May wrote:
Sounds like the xsession is dying. In typical fashion, errors will most likely get logged to $HOME/.xsession-errors, but not shown to the user.
yep, looked there. no sign of any problem.
Another hidey-hole for problems is in ~/.cache/sessions I have the following lines in rc.local: rm -f /home/<user>/.cache/sessions/xfce4-session-<host>:0 rm -f /home/<user>/.cache/sessions/xfce4-session-<host>:0.bak Easy enough to check on this with a text login and see if it exists before doing the graphical login.
Allan Duncan <amd2345@fastmail.com.au> wrote:
Another hidey-hole for problems is in ~/.cache/sessions
I wasn't aware of that one - interesting. Perhaps too obvious to mention is /var/log/Xorg0.log, though that's for X server messages rather than session-related errors. My current system doesn't have this file; it has probably all been migrated to the Systemd journal. The more I use systemd (including the journal) the more comfortable I am with it. I know it has ts detractors on this list, so let's agree to differ.
On 30/03/15 23:10, Jason White wrote:
Allan Duncan <amd2345@fastmail.com.au> wrote:
Another hidey-hole for problems is in ~/.cache/sessions
I wasn't aware of that one - interesting.
Perhaps too obvious to mention is /var/log/Xorg0.log, though that's for X server messages rather than session-related errors.
My current system doesn't have this file; it has probably all been migrated to the Systemd journal. The more I use systemd (including the journal) the more comfortable I am with it. I know it has ts detractors on this list, so let's agree to differ.
No, I have systemd and XFCE writes it when I log out (or is it when it is shut down via the session gui?). I never did nail exactly where and why it was generated, I found it out by trawling the entrails of failed sessions, deleting each newly time stamped item until I found the culprit.
On Tue, Mar 31, 2015 at 02:32:22PM +1100, Allan Duncan wrote: re: /var/log/Xorg.0.log
No, I have systemd and XFCE writes it when I log out (or is it when it is shut down via the session gui?). I never did nail exactly where and why it was generated, I found it out by trawling the entrails of failed sessions, deleting each newly time stamped item until I found the culprit.
nope. it's the X server log. nothing to do with xfce. it's written dirctly by /usr/bin/X (or maybe the wrapper scripts around X) when X starts up, even before the display manager (gdm, lightdm, etc) is started. it should be there long before xfce even starts, if you have to wait for xfce to exit before it appears then something's wrong. craig -- craig sanders <cas@taz.net.au> BOFH excuse #272: Netscape has crashed
Craig Sanders <cas@taz.net.au> writes:
On Tue, Mar 31, 2015 at 02:32:22PM +1100, Allan Duncan wrote:
re: /var/log/Xorg.0.log
[...is] the X server log. nothing to do with xfce. it's written dirctly by /usr/bin/X (or maybe the wrapper scripts around X) when X starts up, even before the display manager (gdm, lightdm, etc) is started.
\begin{pedant} At least xdm starts *before* the X server. It's xdm that *starts* the X server. I assume this also applies to fancier DMs, though obviously the "greeter" GUI bits can't attach to the X server until it's up. \end{pedant}
2015-04-08 3:42 GMT+02:00 Trent W. Buck <trentbuck@gmail.com>:
At least xdm starts *before* the X server. It's xdm that *starts* the X server.
I've neve gone into details, but that's a question which sometimes comes up in my mind: how does a graphical DM render images on the screen? Does it interface with some drivers, or with an X-server? In the second case X starts before the DM (and it's then restarted by the DM). I always answer myself: "it's open-source! You can download the sources, and look how it is implemented". But I don't follow my own suggestion very often :-P -- Mick
On Wed, 8 Apr 2015 09:41:33 AM Michele Bert wrote:
2015-04-08 3:42 GMT+02:00 Trent W. Buck <trentbuck@gmail.com>:
At least xdm starts *before* the X server. It's xdm that *starts* the X server.
I've neve gone into details, but that's a question which sometimes comes up in my mind: how does a graphical DM render images on the screen? Does it interface with some drivers, or with an X-server? In the second case X starts before the DM (and it's then restarted by the DM).
ps axf is your friend: 1359 ? Ss 0:00 /usr/bin/kdm -config /var/run/kdm/kdmrc 1363 tty7 Rs+ 118:47 \_ /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-xymEhc 1483 ? S 0:00 \_ -:0 2425 ? Ss 0:00 \_ /usr/bin/ck-launch-session /usr/bin/dbus- launch --exit-with-session /usr/bin/startkde The above is from my laptop. You can see that kdm (the X login program) started the X server and the "-:0" process that launched the session. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
2015-04-08 11:51 GMT+02:00 Russell Coker <russell@coker.com.au>:
On Wed, 8 Apr 2015 09:41:33 AM Michele Bert wrote:
2015-04-08 3:42 GMT+02:00 Trent W. Buck <trentbuck@gmail.com>:
At least xdm starts *before* the X server. It's xdm that *starts* the X server.
I've neve gone into details, but that's a question which sometimes comes up in my mind: how does a graphical DM render images on the screen? Does it interface with some drivers, or with an X-server? In the second case X starts before the DM (and it's then restarted by the DM).
ps axf is your friend:
Interesting. My Ubuntu 12.04 (without any graphical session - I just logged in through ssh) gives: 1064 ? Ssl 0:00 gdm-binary 1104 ? Sl 0:00 \_ /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 1140 tty7 Ss+ 0:08 \_ /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-hKBUNV/database -nolisten tcp vt7 1724 ? Ssl 0:00 \_ /usr/bin/gnome-session --session gdm --autostart=/usr/share/gdm/autostart/LoginWindow/ 1730 ? Sl 0:25 | \_ /usr/lib/gnome-settings-daemon/gnome-settings-daemon 1838 ? Sl 0:03 | \_ metacity 1859 ? Sl 0:35 | \_ /usr/lib/gdm/gdm-simple-greeter 1866 ? S 0:00 \_ /usr/lib/gdm/gdm-session-worker And after logging into the graphical desktop: 1064 ? Ssl 0:00 gdm-binary 1104 ? Sl 0:00 \_ /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 1140 tty7 Ss+ 0:10 \_ /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-hKBUNV/database -nolisten tcp vt7 1866 ? Sl 0:00 \_ /usr/lib/gdm/gdm-session-worker 4530 ? Ssl 0:01 \_ gnome-session --session=ubuntu-2d 4627 ? Ss 0:00 \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session --session=ubuntu-2d 4638 ? Sl 0:01 \_ /usr/lib/gnome-settings-daemon/gnome-settings-daemon 4657 ? Sl 0:00 \_ metacity 4668 ? Sl 0:00 \_ unity-2d-panel 4669 ? Sl 0:01 \_ unity-2d-shell 4677 ? Sl 0:00 \_ bluetooth-applet 4681 ? Sl 0:00 \_ /usr/lib/gnome-settings-daemon/gnome-fallback-mount-helper 4692 ? Sl 0:01 \_ nautilus -n 4693 ? Sl 0:00 \_ /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 4694 ? Sl 0:00 \_ nm-applet 5294 ? Sl 0:00 \_ /usr/lib/gnome-disk-utility/gdu-notification-daemon 5535 ? Sl 0:00 \_ telepathy-indicator 5777 ? Sl 0:00 \_ gnome-screensaver 7632 ? Sl 0:00 \_ update-notifier I'd expect the PID of Xorg to be changed (if it was restarted), but it actually didn't. If I understand well, the DM starts the X server, than it reuses the same for the user logging in... -- Mick
2015-04-08 12:18 GMT+02:00 Michele Bert <micbert75@gmail.com>:
And after logging into the graphical desktop:
But after I've loged out, the X server has been restarted: 1064 ? Ssl 0:01 gdm-binary 5540 ? Sl 0:00 \_ /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 5542 tty8 Ss+ 0:00 \_ /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-harX5R/database -nolisten tcp 5565 ? Ssl 0:00 \_ /usr/bin/gnome-session --session gdm --autostart=/usr/share/gdm/autostart/LoginWindow/ 5571 ? Sl 0:00 | \_ /usr/lib/gnome-settings-daemon/gnome-settings-daemon 5590 ? Sl 0:00 | \_ metacity 5603 ? Sl 0:00 | \_ /usr/lib/gdm/gdm-simple-greeter 5613 ? S 0:00 \_ /usr/lib/gdm/gdm-session-worker -- Mick
On Wed, 8 Apr 2015, Michele Bert <micbert75@gmail.com> wrote:
And after logging into the graphical desktop: But after I've loged out, the X server has been restarted:
It's a common practice to restart the X server at the end of a session. That frees all resources and ensures that no inappropriate access remains. There is no need to restart the X server after authenticating the user as the X server wouldn't have allocated much memory (it generally only uses basic X functionality to authenticate a user) and the session will only be used by the same user. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Michele Bert <micbert75@gmail.com> writes:
2015-04-08 12:18 GMT+02:00 Michele Bert <micbert75@gmail.com>:
And after logging into the graphical desktop:
But after I've loged out, the X server has been restarted:
That is necessary because the dm has given the cookie to the previous logged-in user, so they could have left Nasty Things around. Restarting X is the safest and simplest way to guarantee the next user to login is protected from the previous user.
On 08/04/15 19:41, Michele Bert wrote:
I've neve gone into details, but that's a question which sometimes comes up in my mind: how does a graphical DM render images on the screen? Does it interface with some drivers, or with an X-server?
Traditionally it just talks to the X server (either the one it started, or it can be on a remote machine). Glenn -- sks-keyservers.net 0x6d656d65
Michele Bert wrote:
2015-04-08 3:42 GMT+02:00 Trent W. Buck <trentbuck@gmail.com>:
At least xdm starts *before* the X server. It's xdm that *starts* the X server.
I've neve gone into details, but that's a question which sometimes comes up in my mind: how does a graphical DM render images on the screen? Does it interface with some drivers, or with an X-server? In the second case X starts before the DM (and it's then restarted by the DM).
I assume the logic is something like run X in the background (root gets the MIT cookie) wait until it's "up" connect to it over X do a bunch of X requests to draw the greeter <pam auth magic> put the MIT cookie where the user can read it close the greeter window spawn a user-owned process running /etc/X11/Xsession IOW it draws the greeter by talking X to the X server. I'm 100% certain that's how xdm and gdm2 work. I'm not as confident about others, but using directfb or something would be silly.
Brian May writes:
Sounds like the xsession is dying. In typical fashion, errors will most likely get logged to $HOME/.xsession-errors, but not shown to the user.
I not entirely sure how lightdm works, but try looking in $HOME/.xsession-errors after a dud login, and see if that helps.
FYI, this is done by /etc/X11/Xsession on Debian, or /etc/X11/xinit/Xsession on CentOS last time I looked. AFAIK Debian patches all DMs to use that as "Default Session"; if you choose a different DE from the DM chooser, all bets are off.
2015-03-30 1:45 GMT+02:00 Trent W. Buck <trentbuck@gmail.com>:
Sounds like the xsession is dying. In typical fashion, errors will most likely get logged to $HOME/.xsession-errors, but not shown to the user.
Just a guess: if you have any /tmp/.X*, try to delete them (needs root rights) -- Mick
participants (10)
-
Allan Duncan -
Brian May -
Craig Sanders -
Daniel Jitnah -
Glenn McIntosh -
Jason White -
Michele Bert -
Russell Coker -
Trent W. Buck -
trentbuck＠gmail.com