If you are unsure which commands you have in the queue, you can check with the atq command:

tigger$ atq

1 2005-02-26 00:00 a kalle

This shows the job number in the first column, then the date of the planned execution, a letter specifying the queue used (here a, you can have more than queue — something that is rarely used and that we will not go into here), and finally the owner of the job.

If you decide that it wasn't such a good idea after all to submit that command, you can cancel a job if you know its job number—which you now know how to find out using the atq command, in case you have forgotten the output of the at command when you submitted the command in the first place.

Deleting a job from the queue is done using the atrm command. Just specify the job number:

tigger$ atrm 1

atrm is one of the more taciturn commands, but you can always use atq to see whether everything is as expected:

tigger$ atq

Not much talk, either, but your command is gone.

Managing System Logs

The syslogd utility logs various kinds of system activity, such as debugging output from sendmail and warnings printed by the kernel. syslogd runs as a daemon and is usually started in one of the rc files at boot time.

The file /etc/syslog.conf is used to control where syslogd records information. Such a file might look like the following (even though they tend to be much more complicated on most systems):

*.info;*.notice /var/log/messages

mail.debug /var/log/maillog

*.warn /var/log/syslog

kern.emerg /dev/console

The first field of each line lists the kinds of messages that should be logged, and the second field lists the location where they should be logged. The first field is of the format:

facility.level [; facility.level ... ]

where facility is the system application or facility generating the message, and level is the severity of the message.

For example, facility can be mail (for the mail daemon), kern (for the kernel), user (for user programs), or auth (for authentication programs such as login or su). An asterisk in this field specifies all facilities.

level can be (in increasing severity): debug, info, notice, warning, err, crit, alert, or emerg.

In the previous /etc/syslog.conf, we see that all messages of severity info and notice are logged to /var/log/messages, all debug messages from the mail daemon are logged to /var/log/maillog, and all warn messages are logged to /var/log/syslog. Also, any emerg warnings from the kernel are sent to the console (which is the current virtual console, or a terminal emulator started with the -C option on a GUI).

The messages logged by syslogd usually include the date, an indication of what process or facility delivered the message, and the message itself—all on one line. For example, a kernel error message indicating a problem with data on an ext2fs filesystem might appear in the logfiles, as in:

Dec 1 21:03:35 loomer kernel: EXT2-fs error (device 3/2):

ext2_check_blocks_bit map: Wrong free blocks count in super block,

stored = 27202, counted = 27853

Similarly, if an su to the root account succeeds, you might see a log message such as:

Dec 11 15:31:51 loomer su: mdw on /dev/ttyp3

Logfiles can be important in tracking down system problems. If a logfile grows too large, you can empty it using cat /dev/null > logfile. This clears out the file, but leaves it there for the logging system to write to.

Your system probably comes equipped with a running syslogd and an /etc/syslog.conf that does the right thing. However, it's important to know where your logfiles are and what programs they represent. If you need to log many messages (say, debugging messages from the kernel, which can be very verbose) you can edit syslog.conf and tell syslogd to reread its configuration file with the command:

kill -HUP `cat /var/run/syslog.pid`

Note the use of backquotes to