My xdm heresy

June 18, 2011

My xdm heresy is that I don't like it and don't use it and never have (at least not on my main machines, the ones that run my full environment). This has nothing to do with xdm itself (I don't like any of the xdm alternatives either) and everything to do with how much of a hack the xdm model of 'logging in' is.

Unix has long had a well defined model of how you log in and establish your environment, where the shell that was directly started by login (and later sshd and so on) was a special 'login shell' that did additional initialization. Unfortunately, Unix tied together two separate ideas in the process of doing this, partly out of necessity in the early days: non-interactive things that you wanted to do once to set up your environment, and interactive things that you wanted to do when you logged in (in the old days, this could include environment setup things such as asking you what sort of serial terminal you were using and initializing it).

This is a bad fit for what xdm wants to do, to put it one way; xdm is effectively a non-interactive login. Xdm isn't the first program to run into this issue; the wheels started coming off the classic Unix login model the moment rsh introduced the ability to run commands on a machine without actually logging in.

What xdm should have done is try to solve the problem once and for all, ideally by introducing the idea of a non-interactive 'login' shell that merely initialized the environment and then ran more commands for you. Failing that, it should have introduced a standard for 'this is how xdm will invoke something to set up your login environment'. Instead it simply ignored the problem. (Given that rsh had also ducked addressing the problem, xdm was following a well-blazed path.)

Ignoring the problem was and is a hack. It works (and worked) sometimes but not always, and of course it created a whole series of workarounds with their own new set of issues. The centrality of this hack and the resulting uncertainty in how xdm works (or doesn't work, depending on local factors) irritates me. As a result I prefer to get around the whole issue by logging in on the text console and then starting X by hand, and I've done it this way for a very long time.

(Starting X by hand may be difficult, but at least I don't feel like my entire environment is built on changeable quicksand. Also, it makes me grumpy to hack my own environment up to cope with the fallout from xdm's bad hack.)

(For an example of the sort of problems that this xdm hack and attempts to work around it cause, see for example this.)

Comments on this page:

From at 2011-06-18 12:04:03:

The solution I use on my machines, is a .zlogin with:

 # Dead Simple Display Manager: on tty1 run X if running the default kernel.
 if [ $(tty) = /dev/tty1 ] && grep -q resume /proc/cmdline; then
   while xdpyinfo -display :$dpy &>/dev/null; do
   startx -- :$dpy &!
From at 2011-06-18 12:06:18:

(zsh also solves the "environment problem" by always sourcing .zshenv...)

From at 2011-06-19 12:32:40:

ALT Linux runs a non-interactive login shell for *dm logins:

$ grep session /etc/X11/xdm/xdm-config 
DisplayManager*session:		/etc/X11/Xsession

$ head -n1 /etc/X11/Xsession          
#!/bin/bash -login

Other packaged display managers also start the user session through the same /etc/X11/Xsession script, which then also sources $HOME/.xprofile (useful for X-specific login session setup).

By cks at 2011-06-20 10:42:59:

There are two problems with what ALT Linux is doing here. First, it is assuming that everyone is using bash as their shell. Second, it assumes that 'bash -login' as a #! line will actually do a non-interactive login, as opposed to explode messily because people were making the reasonable assumption that their .profile would be run only on normal login shells.

The way to do this properly is for xdm to prominently document these things. Of course it can't, since 'everyone must use bash as their login shell in order to use xdm' is officially a non-starter even in today's Linux world.

(Oh, distributions are doing it unofficially, but there would be the usual sort of firestorm if it became official policy.)

Written on 18 June 2011.
« cgroups: so close and yet so far away from per-user fair scheduling
The Unix shell initialization problem and how shells should work »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Jun 18 03:13:58 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.