[2315] in athena10
[Debathena] #208: graphical login doesn't deal well with being
daemon@ATHENA.MIT.EDU (Debathena Trac)
Thu Apr 16 23:02:11 2009
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@mit.edu
To: geofft@mit.edu
Date: Fri, 17 Apr 2009 03:01:52 -0000
Reply-To:
Message-ID: <043.da6f47b1b14e683c2885a48ad4e96517@mit.edu>
Content-Transfer-Encoding: 8bit
#208: graphical login doesn't deal well with being unplugged-------------------+--------------------------------------------------------
Reporter: geofft | Owner:
Type: defect | Status: new
Priority: major | Component: --
Keywords: |
-------------------+-------------------------------------------------------- There are a couple of problems with machines that don't have network
access and try to do network login.
First, there's no clear error explaining what's wrong when the machine
isn't connected and you try to log in. One possible solution to this is a
PAM module that tries to access the network and displays a fatal message
if it can't, although we'd have to be very sure it doesn't have any false
positives. (For instance, if some but not all of the Kerberos servers go
down, we shouldn't deny login.)
Second, if the machine goes offline, it's possible for an AFS access to
time out and make the AFS client sad until "fs checks" is run. Other
services like zhm can also become unhappy. Again, we could hack a PAM
module to address this; there might be cleaner solutions. An Xsession.d
script, for instance, is slightly cleaner.
aseering on testers@:
> > Hey,
> > The !DebAthena computer adjacent to M12-182-4 (it doesn't have a
label
> > and I can't log in to check) is currently sad. Its Ethernet cable was
> > unplugged when I walked up to it. I plugged it back in, and tried to
> > log in; the login hung while trying to render my applications bar. I
> > killed X (ctrl-alt-bksp); the machine is now sitting at a text
console.
mitchb's reply:
> You didn't try rebooting it? If the network cable has been out for
> a length of time, a whole bunch of things on the machine are going
> to have noticed (among them, AFS, zhm, syslogd, aptitude, etc.), and
while
> they may recover given time, assuming that the machine will immediately
> be fine upon reinserting the cable is generally not accurate.
-- Ticket URL: <http://debathena.mit.edu/trac/ticket/208>Debathena <http://debathena.mit.edu/>MIT Debathena Project
