Ticket #801 (closed defect: fixed)
warning on the login screen if essential local services are down
| Reported by: | geofft | Owned by: | |
|---|---|---|---|
| Priority: | high | Milestone: | Natty Beta |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
If things like openafs-client or cron (for auto-updates) or networking or debathena-mit-automounter or whatnot don't start up, we probably shouldn't pop up a cheery login screen. There should be a warning of some sort, and preferably a fatal error if it's a cluster machine (since there are no local accounts that would work without most of these things).
Change History
comment:2 Changed 14 years ago by jdreed
Is there a good way to do this on the login screen? Aren't there issues with inotify in AFS? Seems like we'd either have to be checking periodically (thus preventing power-saving), or do something horrible like trigger on mouse movements. Does clicking the "Log In" button emit any d-bus signal or something? Or can we hook into after the username is entered, when the session options pop up?
Failing that, I suppose we could go with an Xsession.d script that checks for $HOME and if it's not there, tells the user they lose. Really, it's AFS that makes people the most sad. If networking is down, they should, in theory, get the "cannot contact the Athena login servers" thing.
comment:3 Changed 14 years ago by jdreed
We discussed this a bit at release-team:
- If bind9 is broken, users will get the "Cannot contact the Athena login servers" error (right? Someone should test this.)
- If network is down, they'll get the same thing.
- If Hesiod is borked, their username won't exist.
So really, this is just about AFS, and we should do in Xsession.d
comment:5 Changed 14 years ago by jdreed
- Status changed from committed to development
Er, this inadvertantly moved to development when I uploaded xsession 1.17.
comment:6 Changed 14 years ago by jdreed
Once #838 gets fixed, this will mostly work. Users will still lose when their fileserver is flaking or something. In the bad-ideas realm, we could us the "session ending" D-bus signal to cause one of our login applets to run "fs checks", and then either cancel session-ending (we can do that, right?) or briefly whine at the user that they're about to lose. Or we can see if there's some D-bus signal we can catch when the username is entered but before the password is.
