Example of a careful runlevel script

Michael A. Peters mpeters at mac.com
Sat Jun 21 19:39:51 PDT 2003

On Sat, 2003-06-21 at 18:40, Dagmar d'Surreal wrote:

> 1. This is the same issue it's always been.  You fail to see the problem
> with attempting to spawn something from inittab without doing sanity
> checks first, and then you make irrelevant and unrelated arguments while
> attempting to disprove the shortcomings of the opposing viewpoint. 

Well, you NEVER EVER demonstrated why starting gdm from inittab was bad.
You gave a few examples that had no merit - and when I tried them
pointed out that they were baseless - you simply said that starting gdm
from the init tab was bad and expected me to believe it.

> 2. Then think _more_.  The level of skill you've been demonstrating so
> far tells me that you work in either a non-profit or college computing
> department as an intern, if you do any professional system
> administration at all.

Don't try to play that game of classifying me into a group that just
isn't as good as you.

That is extremely rude.
Putting someone into a lower class because they don't agree with your
methodology or views is also not an honest way to discuss something.

> You're right, the admin won't be doing it--the *machine* will be doing
> it because administrators can't be there all the time.  If you insist on
> throwing out "the admin will do it manually" as a solution to
> everything, you will never be able to manage more than 20-25 machines by
> yourself.  

Give me a break.
If you got a machine with messed up libraries you NEED an admin there.
You need to know exactly why libraries are messed up, if it is a
hardware issue or if the system was compromised, etc.

You don't want a machine with a corrupt file system running unless an
admin is running it.

> Here's a nice rhetorical question for you... if two admins each have to
> fix a production machine that's lost a few libraries after a powerfail
> condition, and one brings his machine down and restores a backup over
> the network to fix the problem, and the other one uses the package
> manager on the machine to figure out which files are missing and replace
> those files (which is something one can easily script... Hi there IBM!) 
> which admin will be keeping their job during the next round of layoffs?

That assumes that the data being restored is available in a package.
contents of /home will not be.

But anyway - if you have a power failure that has caused libraries to be
creamed, you will be shot into single user mode when the machine boots.
You will need to run fsck on the partition. You can verify the packages
on the system after running fsck (using rpm or whatever - assuming the
rpm database has integrity - or you have up2date backup of it elsewhere)
at that time and repair any packages that fail the integrity test.

This would be done with an administrator present, btw - and you would
not want the machine running and available to non admins until it was
properly restored.

> Sitting and staring at the console while a backup runs might make dim
> bosses think you're doing a lot of work, but *smart* bosses will not
> care how you do it or where you are when you do it so long as you get
> results with alacrity and the office can get on with their "real"
> work... plus, they'll expect you do be able to do multiple things at one
> time.  

Restoring from backup is for cases where the damaged filesystem is not
packaged - such as /home and was NEVER meant to be the only means by
which a system could be restored.

> > When repairing a filesystem, I always boot from a floppy or CD.
> > Connect to network to retrieve backup. I suspect most do the same -
> > rather than booting into 5 or 3 on a filesystem that they know has a
> > muffed up /usr/lib.
> So what part of the fact that if runlevel 4/5 has been reached, then
> fsck has declared the filesystem sane enough to mount rw has eluded you
> this time?  If fsck has somehow made the wrong decision, then you need
> to fix the scripts you're using to mount all your filesystems so that
> the higher runlevels are never reached.  This whole mindset that you've
> got which seems to indicate you think there'll always be an admin
> present when a machine boots up is /broken/.

I am of the assumption that if there is a filesystem problem, the
problem will most likely be detected by fsck upon boot and no one should
use the system until an admin has dealt with it.

If a filesystem corruption is not detected during fsck AND you are in an
environment where the operator is not the admin or there isn't a local
operator, then your intrusion detection system (tripwire or whatever)
should detect that there is a problem and notify the admins.

>   Thinking like that will
> keep you from ever being able to effectively manage more than 20 or so
> machines by yourself.

Stop it with the superioristic attitude.
I know I bruised you ego with the gdm thing when I specifically called
into question your objections to starting it from an initscript.

That's life. Deal with it. Move on.

> Anyway, I've fixed the typo in my plonk filter now, and clearly you're
> more interested in worshipping at the altar of RedHat

OK. Let me make something very clear.
I brought Red Hat up because they start gdm from the initscript.
Red Hat has an extremely large user base.
Red Hat has a lot of people claiming about problems because of the way
Red Hat does something.

That being the case, since starting gdm is NEVER EVER the cause of any
problems people have - that does indicate that it probably is not as bad
as you say it is.

I asked on this list specifically what I could do to simulate a
situation where starting from an inittab would be bad. The only response
I got was to try removing the mouse. I did that - and there were no
issues that would not also happen with starting it from the inittab.

The fact that you think I used Red Hat because I'm fond of them is an
indication that it is yet another attempt to put me in a lower class
than you, not an honest way to argue - or that you simply did not grasp
the point of what I was trying to say by bringing Red Hat into the

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 mailing list