ugh.book

Keeping Unix Running and Tuned 225

Compilation exited abnormally with code 1 at

Sat Feb 29 17:01:34

I was started to get really worked-up for a flaming message about

Unix choking on leap-year dates, but further examination—and what

example of unix lossage does not tempt one into further, pointless,

inconclusive, disheartening examination?—shows that the actual bug

is that this machine has been up too long.

The way I discovered this was when the ispell program told me:

swap space exhausted for mmap data of

/usr/lib/libc.so.1.6 is not a known word

Now, in a blinding flash, it became clear that in fact the poor

machine has filled its paging space with non-garbage-collected, non-

compactible twinkie crumbs in eleven days, one hour, and ten min-

utes of core-dumping, debugger-debugging fun.

It is well past TIME TO BOOT!

What’s so surprising about Richard Mlynarik’s message, of course, is that
the version of Unix he was using had not already decided to reboot itself.

You Can’t Tune a Fish

Unix has many parameters to tune its performance for different require-
ments and operating conditions. Some of these parameters, which set the
maximum amount of some system resource, aren’t present in more
advanced operating systems that dynamically allocate storage for most sys-
tem resources. Some parameters are important, such as the relative priority
of system processes. A sysadmin’s job includes setting default parameters
to the correct values (you’ve got to wonder why most Unix vendors don’t
bother setting up the defaults in their software to match their hardware con-
figurations). This process is called “system tuning.” Entire books have
been written on the subject.

System tuning sometimes requires recompiling the kernel, or, if you have
one of those commercial “open systems” that doesn’t give you the sources,
hand-patching your operating fix with a debugger. Average users and
sysadmins often never find out about vital parameters because of the poor
documentation.