Re: [gdm-list] a few gdm changes

[Mike Oliver <Mike Oliver Sun COM>]

Ray Strode wrote:
> Hi,
> > > > I really appreciate you helping with this.  Did you also add Failsafe
> > > > login support.
> > > No, I haven't done anything with failsafe.  Mostly I took code that
> > > was there already and turned it on.
> > >
> > > Is failsafe really interesting?  I mean the type of user that can use
> > > a failsafe xterm, could just as easily use the text console for the
> > > same effect right?
> > GDM greeters don't only run on machine consoles, and even when they
> > are on-console not all consoles provide virtual console switching.
> Ah that's true.
>
> > I'm probably an outlier but I use a failsafe session at least a couple
> > of times a week, generally when I want to do something quick on a lab
> > machine and I want maybe a terminal window and one other app without
> > the overhead of starting up and shutting down a complete desktop.
> Okay, so frequently when you use failsafe, you don't use it to recover
> a broken system, but instead use it to initiate a quick, one-off
> custom Xsession?

Right, so for that kind of use an alternative simple
session, defined as just one more desktop choice, would be
fine.  That approach probably covers most of the failsafe
use cases; the circumstances where a specially-handled
"real" failsafe would work and a simple session wouldn't
are pretty rare.

> Maybe for that case we should just offer an "Other..." option in the
> list of sessions that asks for the command to run?

That would be good, especially if this session was defined to
avoid dependencies on the things that usually prevent a full
desktop from starting.  So, for instance, launching 'xterm'
is safer than launching 'gnome-terminal'.  The important
thing is to avoid as much as possible of the processing that
is causing the normal desktop startup to fail.  On Solaris,
for instance, you'd want to avoid executing the Xsession
script because it sources or executes all kinds of things
pulled from various places including user's home directory.
Those are good candidates for breaking your normal desktop
startup and you don't want them to break this simple session
too.

> > And for a more sophisticated user, or an unsophisticated user working
> > under the direction of a support person on the phone, a failsafe
> > session might be extremely useful.
> In situations where virtual consoles aren't available, I agree.
>
> > > Even if we do have failsafe, does it make sense to treat it different
> > > than other sessions?  Maybe we should just ship a desktop file that we
> > > install in /usr/share/xsessions ?  If users of different desktop
> > > environments expect different terminals, then maybe it should be up to
> > > the individual desktop environments to provides the failsafe sessions?
> > That's OK up to a point, and certainly much better than nothing.  It
> > might save your bacon if something (bad update, unnoticed admin typo,
> > rampaging cron job, Gnome version-skew mayhem in an NFS-mounted home
> > directory, ...) has made it impossible to start your normal desktop
> > but has left GDM's session-startup infrastructure intact.  A real
> > failsafe would have minimal dependency on GDM's session-startup
> > stuff so that it could work in spite of damage to those programs
> > and scripts.
> which scripts? Xsession ?

Yes, and PreSession and PostSession too.  If the thing that's
stopping you from getting a normal desktop is a bug in a program
that is launched from PreSession, or a typo in PreSession, it
would be bad if that also prevented you from getting into a
failsafe session.  That's one of the cases where a real failsafe
could work while a severely stripped-down but otherwise normal
session would fail.

Mike.
--
mike oliver sun com