Among different accounting log files, the most significant files are varadmutmp and varadmwtmp from the system logging point of view. Accounting binary log files include raw data
related to the user loginlogout events: utmp refers to actual login sessions, while wtmp contains historical loginlogout data; obviously, special attention should be paid to the file wtmp, because it
grows continuously. Some platforms, like HP−UX, introduce one more file btmp to keep data about bad login attempts separate.
A set of UNIX commands is available to manage these binary files: login, who, write, last, etc. The fwtmp command provided on the HP−UX platform will convert a files raw data into ASCII data,
suitable for further processing. If corrupted, these files could interfere with the regular login procedure; in most cases, a simple removal and recreation of files helps. On the HP−UX platform,
another command wtmpfix is also provided for this situation.
9.3.1 The last Command
The last command displays login and logout information about users and terminals. It looks in the varadmwtmp file which records all logins and logouts for information about a user, a terminal, or
any group of users and terminals. The format of the command is:
last [ −n number | −number ] [ −f filename ] [ name | tty ] ...
The trailing arguments specify the names of users or terminals of interest. If multiple arguments are given, the data applicable to any of the arguments is printed. For example, the command: last root
console lists all of root s sessions, as well as all sessions on the console terminal. The displayed sessions of the specified users and terminals are listed starting from the most recent session first,
indicating the times at which the session began, the duration of the session, and the terminal on which the session took place. The last command also indicates whether the session is continuing or
was cut short by a reboot.
By default all logged data about sessions are displayed in the reverse order. The option −n number, or simply −number can be used number corresponds to the desired number of sessions
to be presented to restrict the display to a certain number of last users sessions.
The option −f filename enables the specification of log file other than the default file varadmwtmp.
The system automatically logs information about each system reboot and addresses them to the pseudo−user reboot. Thus, the command:
last reboot
will give an indication of the mean time between reboots.
9.3.2 Limiting the Growth of Log Files
Log files grow continuously. This is the nature of the logging process; new logging data are appended onto preexisting ones. If left unattended, the number of system log files will grow without
limit, and if a verbose logging is configured, the file growth under some circumstances could be
215
The significance of and the need for regular system logging is beyond question; in a critical moment, the log files could be the only source of information available to trace a problem. System
logging is a requirement and has to be active on every system. However, you must monitor the growth of system log files; the system administrator is responsible for reaping any needed data from
these files and keeping the files to a reasonable size.
The major offenders include: The various system log files in varadm or usrlogs, which may include sulog, messages,
and other files determined in the system logging configuration file etcsyslog.conf, or sometimes determined in the etcdefault directory on some flavors, default values are
defined in this directory. •
Accounting files in the directory varadm or sometimes usradm, especially files wtmp and acct BSD or pacct System V.
• On some UNIX flavors, default subsystem log files originated from different UNIX facilities,
such as cron, printing subsystem, uucp subsystem, etc. The usual names and locations include:
usrspoollplog
Printing log file BSD
usrspoollplogslpsched
Changes to printer status System V
usrspoollplogsrequests
Individual print requests System V
usrlibcronlog
cron log file
usrsbincron.dlog
cron log file SVR4
usrspooluucpLOGFILE
BNU uucp log file •
216
usrspooluucpSYSLOG
usrspooluucpLOG
each contains multiple log files
There are several approaches to control the growth of system log files: The easiest way is to truncate them by hand when they become too large. This is only
possible for ASCII log files. To reduce a file to zero length, use a command like:
cp devnull usradmsulog
or
cat devnull usradmsulog
Copying the null device onto the file is preferable to removing the file because in some cases the subsystem will not recreate the log file if it does not exist.
•
Use the tail command to retain a small part of the current logging information the most recent one, as in the following example:
cd usradm tail −100 sulog sulog.tmp
cp sulog.tmp sulog rm sulog.tmp
The 100 last lines of the sulog file will be retained. •
Keep several old versions of a log file in the system by periodically deleting the oldest one, renaming the current one, and then recreating it. The appropriate command sequence is:
cd usradm cp −p messages.old2 messages.old3
cp −p messages.old messages.old2 cp −p messages messages.old
cat devnull messages
•
The last three versions of the log file usradmmessages are preserved for the eventual need to trace some events in the past. It should to be sufficient if any problem occurs, while it also keeps
disk space consumption at an acceptable level although there is no guarantee for individual log file sizes. Such an approach is ideal for automatic periodic execution, perhaps at the beginning of each
month, so the logging within the last 3 months is always available. Some UNIX flavors integrate this approach in the startup procedure, i.e., the corresponding rc startup script saves and resizes the
system log file usradmmessages in an almost identical way. Under regular conditions, this works very well, but if there are several consecutive system boots, the complete logging from the previous
periods could be lost. Other approaches are, of course, possible. One homemade solution, the check_logfiles.ksh script, is presented in Chapter 8.
217
Chapter 10: UNIX Printing
10.1 UNIX Printing Subsystem
Printing is a very important issue on any UNIX platform, and is important to the job of system administration, as well. Every user on the system expects quick, reliable, high−quality printing at any
time. Many users evaluate a systems performance primarily on its printing capabilities, so this is one of the most sensitive issue from the user standpoint.
As expected, UNIX offers two basic flavors of printing systems: BSD and System V. Unfortunately, the differences between these two flavors are quite significant, making them mutually incompatible.
Neither flavor is more commonly used than the other; both are used widely. Some platforms even support both flavors, but the majority of UNIX systems integrate one of the two available UNIX
printing subsystems.
Before we continue with a more detailed description of the two printing subsystems, let us first define the terminology used for this topic. The common term printing subsystem or sometimes
even printing system identifies the entire suite of all printing related items primarily software, but also hardware items that effectively enable and provide printing on an arbitrary UNIX platform.
Often, a printing subsystem is also identified as a spooling subsystem or printer spooling subsystem. While the first alternative name is too general spooling is not only related to printing —
it can also refer to e−mailing and other queued message subsystems, the second term seems to be quite appropriate. Nevertheless, the spooling subsystem in most cases refers just to the printing.
In the following text, we will try to use the more comprehensive terms among the available ones.
Except for the existing differences between the BSD and System V printing subsystems, the concept of printing in both cases is quite similar. A printing subsystem consists of:
User commands — Required to initiate printing. A user specifies the file to print, the print device to print it on if there is more than one device, and other mandatory and optional
details. The common terminology to identify an invoked printing is also different: on BSD they are called print jobs, on System V, print requests.
•
Queues — To store and sequentially process print jobs print requests. In its simplest form, a queue is a line of print jobsrequests waiting to use a specified print device.
• Spooling directories — To hold pending print jobs print requests. On BSD, the entire file to
be printed is copied in the spooling directory; on System V, by default only a small print request file is generated, while the file to be printed is accessed in its original location at the
proper time when printing actually occurs. •
Server processes — Printing daemons that transfer a print job a print request from the spooling directory to the specified printing device.
• Administrative commands — Print−related administrative commands to start and stop the
printing subsystem or specific printers, and to manage queues and individual print jobs print requests.
•
A functional diagram of a printing subsystem with indicated differences between BSD and System V is presented in Figure 10.1.
218
