Bug 28034

Summary: xdm disables the server if it crashes or fails in the second session
Product: xorg Reporter: John Bowler <jbowler>
Component: App/xdmAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED NOTOURBUG QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Reduce dm.c server-disable timeout, make timeoout from server start none

Description John Bowler 2010-05-08 18:37:00 UTC 
This is reported in:

http://bugs.kde.org/202629

That bug is resolved "upstream", but there is no corresponding bug according to Bugzilla (I searched for bugs.kde.org/202629 and it said 'Zarro bugs found', I am deducing the meaning of this cuteness.)

The bug is also reported multiple times all across the planet - Ubuntu and Gentoo to mention too examples.  Here is the gentoo bug:

http://bugs.gentoo.org/show_bug.cgi?id=278473

That bug contains a complete explanation and a patch (which I will attach later.)

In essence dm.c is imposing a timeout on XOpenDisplay of a local server for the session of 120s, if the XOpenDisplay terminates *within* that time the whole display is disabled (stopDisplay()).

This is reasonable on the first open, but if the server has already opened and closed (done a reset) once it is not reasonable for it to be disabled if it crashes on the second open.

This happens in numerous cases.  In my case the server crashes after the reset (only) somewhere under XOpenFont of the default font (according to the backtrace).  Other people report driver crashes (drivers failing to reset.)  See the plethora of bugs (google).

The patch is to reduce the timeout to something reasonable (I used 20s) and to count the time from the original launch of the server (the very first session.)  The timeout reduction is an absolute requirement - otherwise some guy who types fast (like me) can cheesemonger into the second session and have it crash before (e.g.) the original 120s are passed.  I did that while testing this patch before I reduced the timeout, that really annoyed me.
Comment 1 John Bowler 2010-05-08 18:42:46 UTC 
Created attachment 35514 [details] [review]
Reduce dm.c server-disable timeout, make timeoout from server start

Here's the patch.  It is actually against kdm-4.3.5 but I believe they just copied the DM code verbatim so it should apply here too.  Anyway, it's ridiculously easy to understand because, unlike the original code, there are comments!

BTW, I'm only assuming that the original 120s timeout was meant to deal with precisely this bug - clearly it doesn't, but I assume code rot (after all, the code in question is about old enough to procreate legally in any jurisdiction - let's fix it first.)
Comment 2 John Bowler 2010-05-08 18:54:12 UTC 
Here's additional documentation of the scope of the problem (the title is misleading):

http://martin.feuersaenger.de/2010/01/26/kdm-fails-to-restart-after-logout/

I suspect it has been there for ever, but it may be that it was introduced in a recent change.  If so that change corresponds to some upgrade in KDM 4.x maybe 6 months ago (which is when I started noticing the problem.)  I rather suspect, though, that it may be the xorg server changes to font handling that caused me to start to see the issue (since it may be my use of a font server on a remote machine that exposes the problem.)
Comment 3 John Bowler 2010-05-09 08:51:29 UTC 
I was wrong: this bug doesn't (or shouldn't) appear in xdm.  Sorry: I had not realized how far the KDM backend had diverged from the original (1998) xdm source code.  The timeouts in xdm (server.c) seem to be correct.

I'm going to swap to xdm to see if it is robust in this case (server crashes under XOpenDisplay on second session) but if it isn't the patch is certainly very different.

The timeouts in xdm seem correct (it uses 120s to detect a zombie server but that's fine.)
Comment 4 John Bowler 2010-05-09 10:05:23 UTC 
I've confirmed that this isn't a problem in xdm - it correctly restarts the server after the crash at the start of the second session.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.