Article Listing 1 Listing 2 Listing 3 jun2007.tar

Starting, Stopping, and Replacing Users' Cron Jobs

John Spurgeon and Ed Schaefer

When performing system maintenance, we often disable certain users' cron jobs temporarily. When the maintenance activities are complete, the original crontab files are restored. To facilitate these tasks, we developed two Bourne shell scripts, stop_cron (Listing 1) and start_cron (Listing 2). A related script, replace_cron (Listing 3), was developed to remove a user's current crontab file and replace it with the standard file for that user.

The syntax is similar for each script. The names of users whose crontab files will be affected may be supplied as operands. If no user names are specified on the command line, the list of users is read from standard input. To manipulate another user's crontab file, the scripts must execute with root permissions.

Each script depends on the SortingHat utility, which we discussed in our previous Sys Admin article (April, 2007). SortingHat provides the ability to back up the current version of a file and restore the backup copy -- exactly the type of thing we need to do with users' crontab files. If you don't want to install SortingHat, it should be easy to develop alternative implementations for stop_cron and start_cron. However, changing replace_cron might be more complicated, since the program relies on SortingHat to locate a standard crontab file.

Stop cron

For each user specified, stop_cron first verifies that the user is listed in /etc/cron.d/cron.allow and then checks to see whether the user's crontab file exists in /var/spool/cron/crontabs/. If a crontab file does exist, stop_cron uses SortingHat to create a backup. Then the crontab file is removed using the crontab -r command.

Start cron

Like stop_cron, the start_cron script also checks to make sure a user is listed in the cron.allow file. If a user's crontab file already exists, the script does nothing except inform the user of that fact. Otherwise, start_cron searches for a crontab file to install. The script first looks in SortingHat's backup directory. If the backup file doesn't exist (because the user's cron was not stopped by stop_cron), then the SortingHat -f command is executed to find the user's standard crontab file.

When a crontab file is located, the script ensures that it is owned by and is readable by the corresponding user. Then start_cron uses the su and crontab commands to install the user's crontab file. If a backup file was used, it is deleted.

At this point, you might be wondering why we don't just replace the user's crontab file and forego executing the crontab command. Our cron(1M) man page cautions:

cron only examines crontab or at command files during its own process initialization phase and when the crontab or at command is run.

So, to ensure that cron picks up the change, we use the crontab command. And that's why we need to access SortingHat's internal directories instead of using SortingHat's command interface to do the file replacement.

Replace cron

The replace_cron script simply deletes the user's crontab file by executing the crontab -r command and then calls start_cron. Since the user's crontab file wasn't backed up, start_cron installs the standard crontab file for the user, if one exists. We typically use this script to replace root's default crontab file with our custom version when building a server.

Conclusion

Finally, when using the start_cron, stop_cron, and replace_cron consider these script checks:

1. Set the PATH and other shell variables by sourcing the /etc/setenv_path file. Edit this file to suit your environment.

2. Install the SortingHat utility if you haven't already.

3. Change the SORTING_HAT shell variable if SortingHat is installed in a directory other than /opt/SortingHat.

4. Change the crontabs destination directory if your Unix variant's crontab's location is different from /var/spool/cron/crontabs.

5. Change the CRON_ALLOW shell variable if your Unix variant's cron.allow file exists in a directory other than /etc/cron.d.

References

Spurgeon, John and Ed Schaefer. 2007. "SortingHat -- Which Server Do You Belong In?" Sys Admin 16(4): 59-61. -- http://www.samag.com/documents/s=10123/sam0704j/0704j.htm

John Spurgeon is a software developer and systems administrator for Intel's Factory Information Control Systems, IFICS, in Hillsboro, Oregon. He is currently preparing to ride a single-speed bicycle in Race Across America in 2007.

Ed Schaefer is a frequent contributor to Sys Admin. He is a software developer and DBA for Intel's Factory Information Control Systems, IFICS, in Hillsboro, Oregon. Ed also hosts the monthly Shell Corner column on UnixReview.com. He can be reached at: shellcorner@comcast.net.