Michael A. Peters
mpeters at mac.com
Tue Jun 17 21:41:15 PDT 2003
On Tue, 2003-06-17 at 17:35, Dagmar d'Surreal wrote:
> First off I want to mention for those in the peanut gallery that this
> has zero impact on probably 99% of the installations out there, since
> not all that many places are using full thin-clients on their desktops.
> Secondly, if you accidentally tell X to restart pretty much the same
> thing will happen.
I have never seen a gui admin took where it's possible to accidentally
restart X. However - if you make the display manager an init script, now
every gui admin tool that lets you start/stop/restart init scripts
serves that capacity (effectively)
> The same thing will also happen if you accidentally
> tell the machine to reboot. Worse will happen if you accidentally tell
> the machine to change to runlevel 3 because the poor thin-client users
> won't be able to log back in and will wander around the office like
> zombies looking for support staff to eat until things are made better.
Reboot is on a totally different panel of every gui admin tool I've seen
for UNIX. Not mixed in with the services.
Switching to run level 3 - that exists as a possible mistake wether or
not xdm is an init script. That makes it irrelevent - that is going to
exist as an issue of any tool that allows you to switch the current
> It is a fool's game to try to protect the system from the
Then why do alias rm -i to rm ?
> The system is supposed to do what the administrator asks
> without trying to contradict or second-guess them. The administrator
> for his part is supposed to be competent and not prone to such poor
> motor control that they mis-click and destroy things using a GUI. If
> you want sassback from your systems, run Windows.
You could apply that identical argument to the case for having gdm start
from an init script.
A system administrator should be competent enough when meddling with the
X11 configuration file that he or she shouldn't need to run it as an
init script to "protect themselves from a fury of respawns"
editing that file should be done in run level 3 where you can start
XFree86 independent of your display manager and see that it is properly
> Allow me to introduce you to a concept apropos to critical production
> services called a "maintenance window". If there's a risk the admin can
> crash the main X server and shut down everyone's desktop in the office,
> then the admins are simply not supposed to be screwing around with that
> equipment during working hours, and instead _only_ during a pre-declared
> time period when the entire office knows that all bets are off,
But an admin DOES need to ability to shut a service down or restart a
service at any given point in time. Thus - to apply your concept, start
gdm from the init script - admins should NEVER need to use a tool that
switches runlevel during normal work hours - whereas they do need to be
able to use tools that stop/start/restart services during normal work
> Probably less often than someone with parkinson's does trying to restart
> services with a GUI, but considering that when it _does_ happen (for
> reasons like sticking a USB mouse in when XFree86 is expecting a PS/2
> mouse, which will tank it) you wind up with a madly cycling XFree86 or a
> missing mouse and/or keyboard,
which is why modifications require testing XFree86 from run level 3.
And again - I'm not sure that would affect gdm. I'll try tonight -
unplug my mouse and boot and see what happens.
> it's worth taking that extra moment to
> make sure it'll behave properly. More to the point, anything someone's
> doing devel work on (which I think LFS-based machines would be included
> in by default) is at risk of shared library breakage which could keep
> gdm from running at all.
That's a possibility - it's less likely to affect me as I have an
automated system to check dependencies when upgrading software, but some
people have a disdain for rpm and rpm isn't part of LFS.
It seems, though, that a timout of failed attempts is already built into
respawn because when I was using xdm (before gdm) I first set up with
the path incorrect - very quickly I got a message that it was respawning
too quickly - and it stopped respawning. So the respawn loop issue may
not even be existing with current version of init.
> Not "someone", me. If you have in your config file a mouse device
> specified as CorePointer and it doesn't exist when XFree86 starts, you
> can be very sure that XFree86 will complain about it and exit. You may
> only assign one CorePointer device in the config for 4.3.x, although you
> may merrily have mutliple devices sending signals to it, the CorePointer
> designated pointing device _must_ be there unless you've pre-configured
> XFree86 not to need a pointer at all.
> As to the business about running GDM on a headless server... put down
> the crack pipe and step away from the keyboard. GDM does not care
> whether or not there is a mouse or keyboard present. XFree86 is what
> depends on those, and yes, while it can merrily operate without them, it
> has to be specially configured in advance to not be bothered by the lack
> of them.
I'll find that out tonight when I have the ability to make my system
unbootable for awhile.
I suspect if there is an issue - there won't be, because I believe a
sane check is already in place within init to prevent such loops.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message
More information about the blfs-dev