"The Linux Gazette...making Linux just a little more fun!"

'fsck' Breaks 'man' Pages?

From DrDave on Wed, 27 Jan 1999

Dear answer.guy.jim:

I'm not at all sure this is how one sends questions for the "Answer Guy" column, so if I'm guessing wrong, please let me know how I should do this before piping my message to /dev/rtfm.

Cute. You've guessed correctly on how to post questions. However, you don't normally "pipe" data into "device nodes" and you don't normally store scripts or executables under the /dev/ directory. So I might write a script to autorespond with "RTFM" --- but I'd put it in /bin or (more likely) ~/bin (a.k.a. $HOME/bin). If I had a magic "rtfm" device driver (sounds neat!) I'd redirect or 'cat' the message into it.

Still it's a clever turn of phrase.

Anyway, I've been a Linux user for all of about 72 hours now. The first 24 or so were spent trying to figure out how to recover from some faulty partitioning on my second drive, so we're really only looking at 48.

Do you ever sleep?

So, you can imagine that the "man" command is pretty vital to me...

Well, moments ago, I was running an X11 session and something terribly evil happened which left me unable to properly shutdown my system. When I rebooted, Linux complained about all sorts of problems. Through some miracle (hey, the Pope is in town... coincidence?) I was able to figure out how to manually run fsck as the boot messages suggested. It had to fix a couple of problems in /root, and about 50 zillion in /hdb8 which looked like they were mostly Netscape cache files. Once that was done, I was able to get back into Linux, and now everything seems (so far) to be working fine. Miracles again? Hmmm...

Anyway... that was a bit of a lie. The one thing that isn't working fine is my "man" command. Actually, the command runs just fine, but it can't find any of the appropriate files. In other words, "man ls" returns "No manual entry for ls." I tried locate man | less, thinking that maybe some of the things fsck put in lost and found were actually my man files, but no... those seem to be intact.

OK, you're the Answer Guy, so here's the question:

How exactly does man look up a manual page that you request? Knowing something about that procedure would help me trace my way to the problem, methinks.

I don't know exactly what the 'man' command does. You could read the sources to get some idea of that --- or you could run 'man' under the 'strace' and/or 'ltrace' programs (system call and library function trace utilities for programming and debugging). I suppose you could run it under 'gdb' (the GNU interactive debugger), too.

However, I can give you some general ideas (which will be far more productive than looking at the operations of 'man' through a microscope).

Your 'man' page sources (in groff format) are located under /usr/man in "chapter" directories named: man1, man2, etc. These sources must be processed by the 'man' command according to the method of access (printing or viewing).

The 'man' command maintains a set of cached pages that have been processed by the viewer. Technically I think it uses the 'catman' program to do this. Anyway, these are stored under the /var/catman/ hierarchy. One possibility is that you have some corrupt files under /var/catman.

I supposed there are many others. Your /usr/bin/man binary could be damaged, for example.

In any event it is probably easiest to simply re-install the 'man' package. You don't specify which Linux distribution you are using --- but I'll guess it might be Red Hat. To re-install the man package under Red Hat Linux --- mount your CD (probably by just issuing the command 'mount /mnt/cdrom'), change into the appropriate directory using the 'cd' command (no relation). That directory is likely to be /mnt/cdrom/RedHat/RPMS. Then issue a command like:

rpm -i man-2.3.10-19.i386.rpm

(where the actual filename will probably be different --- since this particular example is from a S.u.S.E. system which maintains its own collection of RPM packages).

If you don't have a CD but you do have Internet access you can use a command like:

rpm -i ftp://$SOME_SITE/$SOME_PATH/man-X.Y.ZZ-X...rpm

... and the 'rpm' command will fetch the file from the site and install it in one operation.

The process is similar for any of the RPM based distributions (Caldera, S.u.S.E.). For Slackware you find the appropriate binary "tarball" on your CD (or on any FTP mirror site). You'd then 'cd' to your root directory and extract the contents of the .tar.gz file using a command like:

tar xzf /mnt/cdrom/.../man-X.YY.Z.tar.gz

(or whatever).

Under Debian you'd use the 'dpkg' command (which I don't know well enough to provide an example of).

If you don't want to just blindly re-install; you'd like to find out a bit more about what went wrong, you can use any of the following:

Red Hat (and other RPM based systems):

rpm -V man

... this will query the RPM database for details about the files that are supposed to be installed as part of the man package and produce a "verification" report (listing any files that are missing, changed or have changed ownership, type or permissions).

rpm -Vp /mnt/cdrom/RedHat/RPMS/man-.....rpm

... this will "verify" the installed files against an RPM file. In other words, it doesn't rely on the local databases but checks the installation against an original source file.

Debian:

dpkg -C $PACKAGE_NAME

(I don't know most of the details on this. I'll have to get another system to run Debian on).

Slackware and other "binary tarball" installations:

cd / && tar dzf $TARBALL_FILENAME

(I hope it's obvious that these $XXXXs that I'm using in these examples are placeholders where you'll have to fill in real values as appropriate. I'm following a common Unix documentation convention of using placeholders that "look like" shell or environment variable names).

The 'tar df' command is (with or without the -z option) is an interesting one. It will describe "differences" between the .tar file (.tar.gz if used with -z, as in my example) and the filenames relative to your current directory. Since Slackware tarballs are relative to the root directory we precede the command with a 'cd'

A practical consequence of this 'd' option to GNU 'tar' (I don't think it's supported under most older versions of 'tar') is that you can also use it with your own backups. Thus if you backup a system using the 'tar' command to a tape drive, you can insert the tape, (rewind it with the command 'mt rewind' or 'mt -f /dev/st0 rewind') and use a command like:

tar df /dev/st0

... to report on all file changes since your backup (or to verify the integrity of the backup depending on what actually happened).

There are similar options to other forms of backup. The 'cpio' command seems to have no option for actually comparing full file contents and meta-data (ownership, permissions, etc) --- just a way to test "CRCs" (checksums). The 'restore' command can be used with its 'C' directive to verify backups made with the 'dump' command.

There are other, more sophisticated, ways to perform filesystem integrity testing (to isolate corrupted files, or detect sabotage). 'tripwire' is the most well known. After many years of being freely available it has now undergone a commercialization effort by one of it's original authors.

Thanks in advance for the answer, or the redirection to a place more appropriate to find it if that's the case.

David Brown

PS Supplemental Question: What do I need to know about all that stuff that fsck did to fix my system? I'd try to look up the rudimentary info about fsck in man, but...

Get your 'man' subsystem fixed or re-installed, then read more about it. You can also read the source code for the 'fsck' command --- and there is supposed to be a very technical description of the low-level ext2 filesystem internals in one of the LDP guides (probably the Programmer's Guide).

To learn more about Linux you can start with the guides on the Linux Documentation Project's web site (http://metalab.unc.edu/LDP). Also at this web site are a couple of hundred HOWTOs, and a few FAQs. These are the best introductory materials available for many of the specific topics that they cover (they are written by users for other users and generally give short "real-world" examples).

MANPATH was the Culprit

where'd my 'man' go?

From DrDave on Thu, 28 Jan 1999

Jim:

I found the problem, which, it turns out, was unrelated to my system burp and forced fsck activity. It was actually related to a change I made in my ~/.bash_profile before the badness happened.

I installed QT, when I was thinking it would be nice to have an ICQ client running on my machine under Linux, and I was trying to get LICQ to work for me (no luck there yet.) One of the recommended changes to .bash_profile was improperly setting $MANPATH so it included only the QT manfile path. I commented those lines out, logged in again and now 'man' works fine.

I'm guessing that setting $MANPATH=/foo causes man to automatically run as if you'd typed 'man -M /foo', and the -d option reports what it sees in the man.conf file rather than what it would use if it were actually going to try to fetch an entry.

Thanks one last time... David

I should have mentioned MANPATH --- though I almost never use it. I thought about it but it didn't relate to the rest of your problem description at all.

In any event it's always a good idea to try commands from a "test" account when they aren't working from your normal login. There are a surprising number of problems you can create for yourself with bad or corrupt dotfiles in your home directory.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 37 February 1999

				1	2	3	4	5	6	7	8	9	10
				11	12	14	15	16	17	18	19	21	22
				23	28	29	30	31	32	33	34	37	38
39	41	42	43	44	45	46	47	48	49