
Hi, yesterday I had a coule of nasty experiences with xdm, the X display manager. Indeed I discovered the when pressing mod-q repeatedly XMonad will quit, instead of restarting, and you will be prompted with a new xdm login screen. I can always reproduce it: start X with xdm, and then login. Press mod-q twice or more and you are out. I cannot reproduce if I connect to Xmd from a remote X server launched with the -query option. For instance: /usr/bin/Xnest -ac -query localhost :1 will not reproduce the error. I cannot reproduce it with Kdm (I did not try with Gdm since it's not installed on my system). Can this be related to the way Xdm manages local sessions? I have the feeling that this could be the problem. By the way it is quite a nasty experience, not different from a crash. And the user should be at least warned. Ciao, Andrea PS: Instruction to run Xdm in a second X server: 1. change /etc/X11/xdm/Xserver to: :10 local /usr/bin/X :10 2. start xdm with: xdm The display you'll have to connect to will be :10. Now you can test the problem.

mailing_list:
Hi,
yesterday I had a coule of nasty experiences with xdm, the X display manager. Indeed I discovered the when pressing mod-q repeatedly XMonad will quit, instead of restarting, and you will be prompted with a new xdm login screen.
I can always reproduce it: start X with xdm, and then login. Press mod-q twice or more and you are out.
I cannot reproduce if I connect to Xmd from a remote X server launched with the -query option.
For instance: /usr/bin/Xnest -ac -query localhost :1
will not reproduce the error.
I cannot reproduce it with Kdm (I did not try with Gdm since it's not installed on my system).
Can this be related to the way Xdm manages local sessions? I have the feeling that this could be the problem.
By the way it is quite a nasty experience, not different from a crash. And the user should be at least warned.
What's in your .xsession-errors? Are you breaking a pipe in your .xsession script? Are you in a race condition of some kind, so you end up forking and failing? -- Don

On Mon, Aug 06, 2007 at 06:32:38PM +1000, Donald Bruce Stewart wrote:
What's in your .xsession-errors? Are you breaking a pipe in your .xsession script? Are you in a race condition of some kind, so you end up forking and failing?
Well, no .xsession-errors, no pipe in my .xsession scripts, no race condition I'm aware of. I reproduced it with a plain, clean xmonad build: no external modules loaded, and no startup scripts at all. Hope to express myself clearly, but I do not think this is a bug in xmonad. I have instead the feeling this is the way xdm works with a client.
From the man page:
"Xdm provides services similar to those provided by init, getty and login on character terminals: prompting for login name and password, authenticating the user, and running a ``session.'' "A ``session'' is defined by the lifetime of a particular process; in the traditional character-based terminal world, it is the user's login shell. In the xdm context, it is an arbitrary session manager. This is because in a windowing environment, a user's login shell process does not necessarily have any terminal-like interface with which to connect. When a real session manager is not available, a window manager or terminal emulator is typically used as the ``session manager,'' meaning that termination of this process terminates the user's session." Does XMonad.restart works with this kind of approach? Can anyone else reproduce it, or it's just my system being broken? This would be a valuable information. Thanks for your kind attention. Andrea

On Mon, Aug 06, 2007 at 10:43:45AM +0200, Andrea Rossato wrote:
Can anyone else reproduce it, or it's just my system being broken? This would be a valuable information.
this is quite important because I'm far from excluding this issue (I tried with a different system - with an older version of X and Xdm, and I cannot reproduce the problem on that system). As I said, perhaps I'm just facing a problem that is specific to my Xdm installation. Sorry for the noise in the ML, but I don't not want to open a ticket if I'm the only one with this problem. Thanks for your kind patience. Andrea

On Mon, Aug 06, 2007 at 06:32:38PM +1000, Donald Bruce Stewart wrote:
What's in your .xsession-errors?
ok, I was eventually able to isolate the issue, an authorization issue: XDM authorization key matches an existing client! xmonad: user error (openDisplay) I was only able to reproduce it on my laptop, with a quite recent version of Xorg. Still it's not clear to me what is causing the problem. Thanks for your kind attention. Andre

On Mon, Aug 06, 2007 at 12:19:47PM +0200, Andrea Rossato wrote:
XDM authorization key matches an existing client! xmonad: user error (openDisplay)
...
Still it's not clear to me what is causing the problem.
I'm not able to find out what exactly is causing the problem (google tells me that everyone is puzzled by that). Still I have found a solution/work around. Just add this line to /etc/X11/xdm/xdm-config: DisplayManager*authName: MIT-MAGIC-COOKIE-1 This way the MIT-MAGIC-COOKIE-1 will be used as the authorization key instead of the XDM-AUTHORIZATION-1 key, which seems to be causing the problem. After that the issue disappears. I found the solution here: http://people.debian.org/~terpstra/message/20070213.103659.e7f758c9.en.html If some of you has a clear idea of what is going on that would be great. You could be the first one to sort this problem out...;-) Ciao Andrea PS: Should we write something about that somewhere or just forget about it?

On Monday 06 August 2007 03:30:00 Andrea Rossato wrote:
Hi,
yesterday I had a coule of nasty experiences with xdm, the X display manager. Indeed I discovered the when pressing mod-q repeatedly XMonad will quit, instead of restarting, and you will be prompted with a new xdm login screen.
I can always reproduce it: start X with xdm, and then login. Press mod-q twice or more and you are out.
I cannot reproduce if I connect to Xmd from a remote X server launched with the -query option.
For instance: /usr/bin/Xnest -ac -query localhost :1
will not reproduce the error.
I cannot reproduce it with Kdm (I did not try with Gdm since it's not installed on my system).
Can this be related to the way Xdm manages local sessions? I have the feeling that this could be the problem.
By the way it is quite a nasty experience, not different from a crash. And the user should be at least warned.
Ciao, Andrea
PS: Instruction to run Xdm in a second X server:
1. change /etc/X11/xdm/Xserver to: :10 local /usr/bin/X :10
2. start xdm with: xdm The display you'll have to connect to will be :10. Now you can test the problem.
I've got a theory: try calling closeDisplay before executeFile in restart. Spencer Janssen

On Mon, Aug 06, 2007 at 10:13:27AM -0500, Spencer Janssen wrote:
I've got a theory: try calling closeDisplay before executeFile in restart.
I tried with no differences. What puzzles me is that I can reproduce this problem only on my laptop, while the other machine I have at home doesn't have this problem (the X version is different, though: x11-6.9 vs xorg-1.3.0 on the laptop). I'd like to understand if something it's wrong with my personal setup or this could be reproduced in other systems too. In the first case no problem since I have a clean solution (change the authorization key). Google seems not to be very helpful with this issue. Ciao Andre
participants (3)
-
Andrea Rossato
-
dons@cse.unsw.edu.au
-
Spencer Janssen