Subject: LSARC FastTrack [10/17/2005]: fbconsole -n I am sponsoring this fast-track for myself, with a timeout on 10/17/2005. Though the original case went to PSARC, I have submitted this to LSARC since it involves the interaction between X and the display manager (dtlogin), which is now normally handled by LSARC. ------------------------------------------------------------------------------ Template Version: @(#)sac_nextcase 1.55 08/11/04 SMI This information is Copyright 2005 Sun Microsystems, Inc. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: fbconsole -n 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 10 October, 2005 4. Technical Description Disconnecting fbconsole from the X display ========================================== Background: PSARC 1992/130 introduced the Fallback Console ("fbconsole"), which runs in the background of X sessions to intercept console messages when no other console listener is running, to prevent the console text interruption of the X server and display corruption that used to plague Sun workstations. In order to exit when the X session closed, fbconsole opens the X display and waits for notice that it's connection to the X session has been terminated. PSARC's opinion on that case included this TCA: Revise the division of responsibility between the fallback console program and .xinitrc to have the latter detect the window server's termination and then kill the fallback con- sole. This change would simplify the fallback console by removing all window system dependencies from it, without making .xinitrc significantly more complicated. fbconsole is now started directly by dtlogin & gdm instead of xinit & the old "openwin" script, but is otherwise essentially unchanged. 13 years after the original case it has become obvious this TCA needs to be implemented, but doing so will require some changes that need an ARC case of their own, since we've shipped too many releases that did not include the TCA'ed changes. Current problem: When connecting to a remote session via XDMCP, the XDMCP protocol specifies that the first client to connect becomes the session controlling client and that the session should be closed when that client disconnects. This causes a race condition between fbconsole and the session manager, and users have found themselves unable to logout of their session when fbconsole wins the race, since the session manager is expecting the session to be closed when it disconnects. To solve this, a new option, "-n" is added to fbconsole to tell it not to connect to the X server, but instead to rely on the display manager to kill it when it is done. The CDE display manager (dtlogin) is then modified to call fbconsole with the "-n" option and to kill it when the session has exited. Since this issue has been escalated by a customer on an existing release, a patch binding is needed for this change. In order to handle a patch delivery between consolidations, the patch implmenting the change to dtlogin will list a dependency on the patch adding the "-n" option to fbconsole. (The new fbconsole will operate exactly the same as the old version if -n is not specified, so it will be safe to have the fbconsole patch without the dtlogin patch, but if dtlogin tries to call the old fbconsole with -n, it will exit with an "illegal option" error.) Existing interfaces imported by this case: ------------------------------------------ fbconsole Private PSARC 1992/130 New interfaces exported by X consolidation: ------------------------------------------- fbconsole -n Consolidation Private New interfaces imported by CDE consolidation: --------------------------------------------- fbconsole -n Contracted Consolidation Private Relationship to other projects: ------------------------------- gdm: The GNOME team will be informed of this change and will need to decide whether gdm should follow suit. Virtual consoles: The virtual console project (RFE 4309501) will be hailed as the panacea of all our woes in this area and may lead to the obsolence of fbconsole altogether (provided that it can arrange for console error messages to go to a different virtual console than the X server is attached to) as well as solving the concerns PSARC raised in the original case of fbconsole simply hiding the error messages where no user is likely to ever see them. Virtual consoles will unfortunately not be available soon enough or in all the releases we need this fix in now to be a solution for the problem being solved by this case. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: Desktop 6.5. ARC review type: FastTrack