Learning the Mac OS X Terminal, Part 3
by Chris Stone02/26/2002
Editor's note -- Chris Stone has recently posted an update to this tutorial for readers using Mac OS X 10.1.5 or later. The update focuses on Sendmail. All other features in this article continue to work as originally discussed.
The series continues in Learning the Terminal in Mac OS X, Automating Mail from the Mac OS X Terminal, Configuring Email from the Mac OS X Terminal, Customizing the Mac OS X Terminal, and Synchronizing Drives with Cron and the Mac OS X Terminal.
However, none of the first three parts of the series will work in Mac OS X 10.2 (Jaguar) or newer. Jaguar brought several major changes to the OS that require significant changes to the procedure. I'll be posting Jaguar compatible updates to these articles shortly.
Now that you have the regular maintenance cron jobs running at more reasonable times and emailing you their reports, you would probably like to know what those jobs do, and what the reports tell you.
Today we'll first look at both of these things, and then finish up with a couple of “variations on the theme” -- additional procedures to make this process even easier (though with their own trade-offs and caveats).
The Daily Script
To begin, let's have another look at the system crontab, specifically the command for the daily job:
sh /etc/daily 2>&1 | tee /var/log/daily.out
| mail -s "`hostname` daily output" root
As you might remember, cron uses the Bourne shell (sh) to run the script found in /etc/daily. The real meat of this cron job, then, exists in that file, which is rather long and complex and would require several articles like this to fully explain. However, the script does contain comments describing each general task, so having a good look at this is informative.
The /etc/daily file is too long to view with cat. Instead, you’ll need an application that can display the files one bite-sized one-screen chunk, or "page," at a time. Such applications are called pagers, and one of the most common pagers is more.
As you did with cat, enter "more" and the file’s pathname to view the first page of the file. To view the daily script, then, enter:
more /etc/daily
To move down to the next page, press the space bar. (To go back up, press B.) At the bottom of the more display, you’ll see the name of the file being viewed, as well as an indicator of the percentage of the file read so far. To exit more, type Q.
As you peruse the script, keep in mind that lines beginning with the #character are ignored as the shell runs through the script. Typically, such lines contain descriptive comments about the script, but they can also be actual command lines that for various reasons are turned off, or "commented out."
A look inside the more window with the percentage of the file read so far.
|
Also, the command lines beginning with echo provides some of the output
that ends up in the report. For example, these first two lines begin the
daily report with a blank line and the quoted line of text:
echo ""
echo "Removing scratch and junk files:"
Again, I can’t detail fully this script here, but what follows are the most pertinent highlights. The skipped parts of the script mostly relate to processes not applicable to a "stock" OS X system.
The first section of the script removes "scratch and junk files" from your system. Specifically, some of these items are:
- Files existing in
/tmpthat haven’t been accessed or changed in at least the last three days. The/tmpdirectory contains, among other things, theTemporary Itemsdirectory used by many GUI applications, so it’s often chock-full of good trash fodder. - Files existing in
/var/tmpthat haven’t been accessed in at least a week, or changed in at least the last three days. Some Unix processes leave junk here as well.
The daily script also performs one of the most important tasks of any in these scripts: backing up your NetInfo database. Should your NetInfo database ever need restoring, you can easily do so using NetInfo Manager (in Applications-> Utilities) and the backed-up database, called local.nibak.
The heading of the next section of the script is, as you can see in the cron report, "Checking subsystem status."
Checking subsystem status:
disks:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/disk0s5 40016844 33274772 6742072 83% /
fdesc 1 1 0 100% /dev
/dev/disk2s1s2 354552 354552 0 100% /Volumes/Q3TA
|
Related Reading 
Mac OS X: The Missing Manual |
This output is a result of the df -k -l command in the daily script, which reports the used and free space on all local disks. This example shows a 40-gigabyte system disk (which will always show as "mounted on" /, or "root") with about 6.7 gigabytes of free space.
You can ignore the fdesc line, which doesn’t refer to any actual disk, but part of the filesystem plumbing.
Any other local volumes you have mounted will also show up in this list. This example shows a disk (in fact, a CD-ROM) mounted on /Volumes/Q3TA. This attribute, known as the disk's "mount point," shows you the path you would take to reach that disk via the CLI. For example, to peek inside the Q3TA CD you would enter ls /Volumes/Q3TA.
You will find all local disks and most network volumes mounted within /Volumes.
The next relevant command simply checks sendmail’s queue for any
undeliverable messages. If the report doesn’t show this directory as empty
(and the procedure in this tutorial is your only use of sendmail) , then
it’s likely you have some sendmail issue.
The daily script then runs the netstat -i command, which outputs the network statistics to the report, a few lines of which look like this:
network:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16384 <Link> 2015 0 2015 0 0
lo0 16384 127 localhost 2015 0 2015 0 0
en1 1500 <Link> 00.30.65.xx.xx.xx 0 0 0 0 0
en0 1500 <Link> 00.30.65.xx.xx.xx 646365 0 670550 0 0
en0 1500 192.168 192.168.0.40 646365 0 670550 0 0
The netstat -i command lists your network interfaces in rows, showing traffic statistics for each (since activation) in the columns. This example actually shows just two hardware interfaces: en1 is an inactive Airport card, and en0 is the active Ethernet port.
You will see some other lines for the IP interfaces, including the "local loop" interface (lo0). At this point, you’ll be fine to only focus on the lines showing "<link>" in the network column. The other pertinent columns are the actual packet-count columns:
Ipkts -- Incoming packets
Ierrs -- Incoming packet errors
Opkts -- Outgoing packets
Oerrs -- Outgoing packet errors
Coll -- Packet collisions
What you should be concerned with, of course, are any non-zero entries in the error and/or collision columns. I won’t go into troubleshooting your network here, but this page might be a good place to start if something does turn up: http://www.princeton.edu/~unix/Solaris/troubleshoot/netstat.html.
  Now that you're up to your knees in command lines, how's it going? | |
The next important job of the daily script is the "rotation" of the system log. This log file, system.log, records the status and error messages from the large number of processes that comprise the OS.
In the case where no backups of system.log yet exist, the script makes the first backup, compresses it using gzip, and numbers it 0. This results in a file called system.log.0.gz. By "rotating" this log file on subsequent days, the script will first rename system.log.0.gz to system.log.1.gz, and then create a new system.log.0.gz.
Each day, the script creates a new system.log.0.gz file after incrementing the other backup filenames by one. Once system.log.7.gz is created, however, there will be no ninth backup file. Instead, on the subsequent backup the system.log.6.gz file (renamed to system.log.7.gz) just overwrites the previous system.log.7.gz file.
This procedure, then, ensures that you’ll have over a week’s worth of logs to refer to in case problems arise, but not so many as to waste disk space, and likely none too large to not view easily.
Next, the script "cleans" the Web server log files by deleting any rotated files that have been around longer than a week.
