Last year, we took a look at the
cron utility in Getting Cron To Do Our
Bidding. In the next two articles, I'd like to take a closer look at the
actual periodic scripts that
cron calls to be executed on a daily, weekly,
and monthly basis.
It's always a good idea to be aware of what scripts are running on your computer. Scripts, after all, do stuff that make them a double-edged sword. On the plus side, they can keep you posted on the overall health of your computer and take care of routine housekeeping tasks for you. With the built-in scripts, you don't have to know how to write a shell script in order to perform routine tasks as your FreeBSD system comes with many pre-made scripts that are automatically run for you. On the negative side, any script can be vulnerable to exploits by malicious users. Just as you shouldn't run services on your computer that you don't need, you should only run the scripts that are useful to you and disable the ones you don't need.
The scripts themselves are found in
/etc/periodic and are placed in the
appropriate subdirectory depending on whether they will be run daily,
weekly, or monthly:
ls -F /etc/periodic ./ monthly/ ../ weekly/ daily/
Each script begins with a number to indicate the order in which the
scripts in that directory will be run. That is, a script beginning with the
number "120" will run before the script beginning with the number "300". Also,
these scripts are executable files as indicated by the
* in the output of
ls -F /etc/periodic/weekly ./ 320.whatis* ../ 330.catman* 120.clean-kvmdb* 340.noid* 300.uucp* 400.status-pkg* 310.locate* 999.local*
Finally, these are Bourne shell scripts (that is, they all begin with the
#!/bin/sh) meaning you can test the output of any of these scripts by running it with
sh like so:
Local system status:
8:25AM up 19 days, 21:34, 7 users, load averages: 0.41, 0.38, 0.29
You may remember that
cron uses the system
crontab file to determine
when the scripts in each directory are to be run. I'll show the relevant
more /etc/crontab <snip> # do daily/weekly/monthly maintenance 1 3 * * * root periodic daily 15 4 * * 6 root periodic weekly 30 5 1 * * root periodic monthly <snip>
cron is told to call a program named
periodic to run the
desired daily scripts every morning at 3:01, the desired weekly scripts every
Saturday morning at 4:15, and the desired monthly scripts at 5:30 in the
morning on the first day of each month. The
periodic program has its own
separate configuration file called
periodic.conf which is used to specify
which of the daily, weekly, and monthly scripts you want to be included in the
run, and which you wish to disable.
Your FreeBSD system comes with a default
periodic.conf file; let's take a
look at the top portion of that file:
This file makes it pretty clear that you should not make any changes to it and offers two locations to store your own customized version of
head -20 /etc/defaults/periodic.conf #!/bin/sh # # This is defaults/periodic.conf - a file full # of useful variables that you can set to change # the default behaviour of periodic jobs on your # system. You should not edit this file! Put any # overrides into one of the $periodic_conf_files # instead and you will be able to update these defaults # later without spamming your local configuration # information. # # The $periodic_conf_files files should only contain # values which override values set in this file. This # eases the upgrade path when defaults are changed and # new features are added. # # $FreeBSD: src/etc/defaults/periodic.conf,v 188.8.131.52 # 2001/07/28 11:44:22 brian Exp $ # # What files override these defaults ? periodic_conf_files="/etc/periodic.conf /etc/periodic.conf.local" # periodic script dirs local_periodic="/usr/local/etc/periodic /usr/X11R6/etc/periodic"
periodic.conf. If you try to find the files that override the defaults, you'll see that they don't exist as it is up to you to create them:
more /etc/periodic.conf /etc/periodic.conf: No such file or directory more /etc/periodic.conf.local /etc/periodic.conf.local: No such file or directory
Before you start making your customized file, it is a good idea to know
what each script does so you can decide whether or not you want it to be
executed by the
Let's take a quick look at each script, what it does, and whether or not
it runs by default. These details are described in
man periodic.conf which I've summarized in the following chart:
|Name of script||Action||Default|
||removes all matching files||NO|
||clears temporary directories||NO|
||removes old files from
||old system messages purged||YES|
||old files in
||old files in
||rotates daily accounting files||YES|
||summarizes mail rejections logged to
||summarizes denied zone transfers||YES|
||manually runs the mail queue||YES|
||list of extra scripts in
||locate files with an invalid owner or group (orphans)||NO|
||uses pkg_version(1) to list out of date installed packages||NO|
||list of extra scripts in
||does login accounting using the
||list of extra scripts in
You'll notice that there are quite a few scripts and most of them are enabled by default. Let's become the superuser and copy the default file to the file that we'll customize:
su Password: cp /etc/defaults/periodic.conf /etc/periodic.conf
I'll then open up
/etc/periodic.conf in my favorite text editor and pick through the interesting lines. Let's start with this bit:
<snip> # Daily options # These options are used by periodic(8) itself to # determine what to do with the output of the sub-programs # that are run, and where to send that output. $daily_output # might be set to /var/log/daily.log if you wish to log the # daily output and have the files rotated by newsyslog(8) # daily_output="root" # user or /file daily_show_success="YES" # scripts returning 0 daily_show_info="YES" # scripts returning 1 daily_show_badconfig="NO" # scripts returning 2
You'll note that by default, the results of running the daily scripts are emailed to root. If you check root's email, you'll see messages with the subject "hostname daily run output" and if you read one of those messages, the output should match up to the daily scripts that are marked as "YES". You can have the output sent to another user by replacing "root" with a user name on the "daily_output" line.
Alternatively, you can specify that the output be sent to a file, usually
/var/log/daily.log. This file doesn't exist by default, so you'll want to create it by using touch
Let's continue by taking a look at the daily scripts. You'll note there is a logic to the layout of the scripts: The first scripts clean out old files, these are followed by backup scripts, which are followed by scripts which run some useful utilities.
# 100.clean-disks daily_clean_disks_enable="NO" # Delete files daily daily_clean_disks_files="[#,]* .#* a.out *.core *.CKP .emacs_[0-9]*" daily_clean_disks_days=3 # If older than this daily_clean_disks_verbose="YES" # Mention files deleted
This script is disabled by default but you may want to consider enabling it if disk space is an issue on your system. If you do enable this option, backup your important files first and check the output to ensure this script didn't delete any files you were attached to. This is especially important if you decide to add your own extensions to the files list.
The next script is also disabled by default and may be worth enabling if disk space is an issue:
# 110.clean-tmps daily_clean_tmps_enable="NO" # Delete stuff daily daily_clean_tmps_dirs="/tmp" # Delete under here daily_clean_tmps_days="3" # If not accessed for daily_clean_tmps_ignore=".X*-lock quota.user quota.group" # Don't delete these daily_clean_tmps_verbose="YES" # Mention files deleted
Before enabling the
clean-tmps script, you should be aware that there is a
security advisory regarding this script which may affect you, depending on
which version of FreeBSD you are running. If you're not yet aware of FreeBSD's security advisories (SAs), you should bookmark and spend some time reading this site.
And, as mentioned at this URL, subscribe to one of the mailing lists that the security advisories are sent to so you will be aware of any new exploits as they are found and fixed. The security advisory that deals with this particular script is FreeBSD-SA-01:40.fts.v1.1.asc.
The next script cleans out
/var/preserve. If you don't know what a directory does on your FreeBSD system,
man hier is the best place to
look. Here I'll search that man page for the word "preserve":
man hier /preserve
preserve/ temporary home of files preserved after an accidental death of an editor; see (ex)1
Now that you know what
preserve is for, you can decide whether or not to
keep this script enabled.
# 120.clean-preserve daily_clean_preserve_enable="YES" # Delete files daily daily_clean_preserve_days=7 # If not modified for daily_clean_preserve_verbose="YES" # Mention files deleted
The next script cleans out messages sent by the
msgs utility. If you don't use this utility, you can disable this script as there won't be any messages to delete. If you're not sure if you're using this utility, you
probably aren't, but you can doublecheck by reading
# 130.clean-msgs daily_clean_msgs_enable="YES" # Delete msgs daily daily_clean_msgs_days= # If not modified for
For the next script, it is again helpful to read the man page for the
utility, in this case
rwho. If your FreeBSD computer is not hooked up to a Unix LAN, you can disable this script as
/var/rwho will always be empty.
# 140.clean-rwho daily_clean_rwho_enable="YES" # Delete rwho daily daily_clean_rwho_days=7 # If not modified for daily_clean_rwho_verbose="YES" # Mention files deleted
You may or may not have a
hoststat on your computer. To see why, check out this thread.
I don't, so I've disabled this script on my computer.
# 150.clean-hoststat daily_clean_hoststat_enable="YES" # Delete .hoststat daily daily_clean_hoststat_days=3 # If not modified for daily_clean_hoststat_verbose="YES" # Mention files deleted
Now we get to the three backup scripts. You definitely want your password and group files backed up daily. This script not only backs them up, it will also report if either of those two files had any changes made to them that day. The output of this script should be checked on a daily basis.
# 200.backup-passwd daily_backup_passwd_enable="YES" # Backup passwd & group
It is a good idea to have a backup of your mail aliases file; whether or not you want to have it backed up daily is up to you.
# 210.backup-aliases daily_backup_aliases_enable="YES" # Backup mail aliases
Unless you are using
rdist to maintain identical copies of files over multiple hosts, you won't have an
/etc/Distfile and you can disable the script that backs it up.
# 220.backup-distfile daily_backup_distfile_enable="YES" # Backup /etc/Distfile
calendar utility is interesting, but not enabled by default. If you like the
fortune program and enjoy reading trivia, you might consider running the
calendar program. There are a few steps involved in setting up
First, decide which calendar file you think you or your users would enjoy
reading. The possible files are found in
cd /usr/share/calendar ls -F . ./ calendar.holiday ../ calendar.judaic calendar.all calendar.music calendar.birthday calendar.russian calendar.christian calendar.usholiday calendar.computer calendar.world calendar.croatian de_DE.ISO_8859-1/ calendar.german hr_HR.ISO_8859-2/ calendar.history ru_SU.KOI8-R/
Each of the files are in plain text so you can safely send them to a pager to see their contents or edit the contents as you wish. Some calendar files contain the actual trivia:
01/01&bnsp; AT&T officially divests its local Bell companies, 1984
01/01&bnsp; The Epoch (Time 0 for UNIX systems, Midnight GMT, 1970)
01/03&bnsp; Apple Computer founded, 1977
01/08&bnsp; American Telephone and Telegraph loses antitrust case, 1982
01/08&bnsp; Herman Hollerith patents first data processing computer, 1889
01/08&bnsp; Justice Dept. drops IBM suit, 1982
01/10&bnsp; First CDC 1604 delivered to Navy, 1960
01/16&bnsp; Set uid bit patent issued, to Dennis Ritchie, 1979
01/17&bnsp; Justice Dept. begins IBM anti-trust suit, 1969 (drops it, 01/08/82)
01/24&bnsp; DG Nova introduced, 1969
While other calendar files are used to specify which trivia files to include:
more calendar.all <snip> #include <calendar.world> #include <calendar.german> #include <calendar.usholiday> #include <calendar.croatian> #include <calendar.russian> <snip>
Any user aware of this directory can see what trivia is suited to
today's and tomorrow's date by invoking the desired calendar file with the
f switch like so:
calendar -f calendar.birthday Nov 4 King William III of Orange born, 1650 Nov 5 Roy Rogers born, 1912
By default, if a user isn't in this directory or doesn't specify the full path name to the desired calendar file, they'll receive this error message:
calendar -f calendar.birthday
calendar: no calendar file: ''calendar.birthday'' or ''~/.calendar/calendar.birthday
To fix this, tell the user to create a directory in their home directory and to copy the desired calendar file(s) to it:
cd mkdir .calendar cp /usr/share/calendar/calendar.world .calendar/calendar
calendar.world as it includes birthdays, computer, music, history,
and holidays. Since I've saved the file as "calendar", I can now simply type
calendar with no arguments, regardless of what directory I'm in:
Nov 4 King William III of Orange born, 1650
Nov 5 Roy Rogers born, 1912
Nov 4 UNIVAC I program predicts Eisenhower victory based on 7% of votes, 1952
Nov 4 Iranian militants seize US embassy personnel in Teheran, 1979
Nov 4 Soviet forces crush the anti-communist revolt in Hungary, 1956
Nov 5 Guy Fawkes' Plot, 1605
Nov 4 Flag Day in Panama
Nov 4 Will Rogers Day
Which brings us back to the periodic script that deals with
calendar. If you enable this script, it will email the customized calendar output to every user who has created a
.calendar file in their home directory. As a side note, the superuser can do this at any time. Once you've set up your calendar directory, become the superuser and type:
If you check your email, you'll have a new message with a subject of "Day_of_the_Week Calendar". If your users think this is a cool feature, enable the periodic script and show them how to set up their calendar directory.
# 300.calendar daily_calendar_enable="NO" # Run calendar -a
Let's stop here for this week and we'll finish looking at the rest of the periodic scripts in the next article.
Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.
Read more FreeBSD Basics columns.
Return to the BSD DevCenter.
Copyright © 2009 O'Reilly Media, Inc.