[Techtalk] Tried fsck'ing it... (fwd)

[Kai MacTane]

At 3/22/02 10:22 AM , Raven, corporate courtesan wrote:
>         Forwarded on behalf of Kai MacTane.  Unfortunately, the machine
>thrashing here is his mail server, which is why Kai can't speak for
>himself.

Following up on this...

The machine is now back together (as you can see from the fact that I'm 
posting on my own behalf, from my usual email address). Eventually, I did 
have to go ahead and reinstall. This time, instead of Red Hat, I was 
persuaded to try out Slackware.

I had previously thought that I wasn't l33t enough for Slackware. I was so 
wrong. Slack was just what the doctor ordered, both for this machine and 
for my own sanity. I guess I'd formed the "I'm not l33t enough" impression 
back when I was new to *nix, and hadn't updated that evaluation when I 
should have (as I grew in knowledge and skill).

>More Google searching says the Ids 1-6 are probably the initial
>(min)gettys loaded by inittab; they're probably aborting too fast
>because some library is hosed. Which would probably mean I'd have to
>reinstall completely unless I can figure out which one.

A friend pointed out that mingetty probably sets a lock somewhere, which 
wasn't cleared in the bad power-down. So when the new mingettys were 
spawned, they all instantly saw that the previous versions had locks on 
/dev/tty[0-5], and immediately exited. "man mingetty" shows nothing in the 
FILES section besides /etc/issue and /var/run/utmp, so my guess is that 
deleting /var/run/utmp might have fixed the problem. (That being a binary 
file, I couldn't just edit it to remove the locks.)

Other notes that may be of interest -- I found out a few things during all 
this, and feel I should pass on the info. (This archive gets spidered by 
Google, right? [goes and checks] Yes, it does. Good.)

Red Hat includes documentation on every package installed in 
/usr/share/doc. I wish they'd do a better job of documenting the fact that 
they've put docs there. (I forget how I even found the stuff. Desperation, 
I think.)

The docs in /usr/share/doc/initscripts-X.xx are particularly interesting -- 
there's a text file that includes a sample, skeleton init script that you 
can turn into your own custom one with little work, and have your services 
put up that nice "[  OK  ]" message in pretty green colors at boot-time.

More importantly, though: It seems Red Hat is in the process of migrating 
the entire /etc/rc.d tree up to /etc. Personally, I don't agree with this 
move, but even assuming it's a good thing to do, they are doing it the 
wrong way. To this end, they have currently put a shitpile of symlinks in 
/etc, pointing to the actual files. (This is one thing I don't like about 
it -- it makes tab-completion completely useless.)

Then, for no earthly reason, they went and edited /etc/rc.d/rc (the script 
that actually processes S and K scripts in the /etc/rc.d/rcN.d directories) 
to make it use *the symlinks* instead of the actual files. And apparently 
that script has never had any error-checking anyway. So there's now a 
structure in there that looks like this:

# Do stuff that sets $runlevel to the runlevel we're moving to

# Is there an rc directory for this new runlevel?
if [ -d /etc/rc$runlevel.d ]; then
     # First, run the KILL scripts.
     for i in /etc/rc$runlevel.d/K*; do
        # stuff omitted
     done

     # Now run the START scripts.
     for i in /etc/rc$runlevel.d/S*; do
        # stuff omitted
     done
fi

I'd like to submit this to the "Basics of Programming" course as an example 
of how *NOT* to do things. First of all, an important system utility like 
this should not rely on symlinks. I'm leaving out the "IMHO" here because I 
think this is a fairly objective design flaw. Second, what happens if there 
*isn't* such a directory? Don't you (i.e., the folks at RH) think that if 
such a directory is missing, this at least warrants a warning message to 
the user?

(Sonja's on this list, right?)

If you're using an RHL system, and you want to remove the rc symlinks in 
/etc, you'll need to edit /etc/rc.d/rc (in a few different places; search 
on "runlevel") and /etc/rc.d/rc.sysinit (just once near the top, where it 
re-execs itself through initlog). Also, be prepared for a variety of RPMs 
to try to find those symlinks during their post-install scripts.

Alternatively, if you're advanced enough that you get into that kind of 
tweaking to your system, consider ditching the Red Hat/Mandrake 
"mass-market" distros in favor of something more hacker-friendly. I was 
scared by Slackware's "uber-haxx0r distro" reputation, and was pleasantly 
surprised to find that, no, it's really just for geeks who are actually 
geeks, as opposed to being for any random who wants to try out Linux.

For anyone else who's wondering about Slackware, I'll be posting my 
impressions on it in a while, under separate cover.

                                                 --Kai MacTane
----------------------------------------------------------------------
"Soft and only you, lost and only you,
  Strange as angels."
                                                 --The Cure,
                                                  "Just Like Heaven"