[476] in athena10
Simulating AFS outages with pyhesiodfs
daemon@ATHENA.MIT.EDU (Jonathan D Reed)
Wed Sep 3 14:29:10 2008
Date: Wed, 3 Sep 2008 14:28:24 -0400 (EDT)
From: Jonathan D Reed <jdreed@MIT.EDU>
To: athena10@MIT.EDU
Message-ID: <Pine.LNX.4.64L.0809031401100.32734@infinite-loop.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
pyhesiodfs seems to behave slightly better in an AFS outage than afuse
did. Here is what I encountered:
-If the locker had already been accessed (say, by a successful login),
then the Failsafe Terminal option will work, but attempts to access
other directories will fail with "Timed out" errors. Presumably this is
due to AFS caching, and might eventually fail if enough time elapses.
-Failsafe GNOME just plain doesn't work (it attempts to create the
Nautilus directories, presumably because it can't read them, and fails)
-If the locker has not already been accessed (say, after a reboot), it
hangs at the login screen, and eventually asks the user if they want to
log in with / as their home directory. If you say yes, it eventually
presents the GNOME background, but just sits there (I gave up after 10
minutes). If you attempt to Ctrl-Alt-Bksp out of the situation, X does
not respawn. ps shows that X and gdmgreeter are defunct processes, but
nothing I tried was able to cause them to completely die or to respawn X.
However, pyhesiodfs seems to recover from server outages much faster than
afuse did.
The situation is still pretty much unusuable, though. Rather than try and
let Ubuntu figure out what's up with the user's homedir, is it worth
adding code to the login sequence that explicitly checks if a user's
homedir is available and punts if it isn't?
