This chapter describes changes made automatically during ClearCase installation to ensure that crontab(1) scripts do not accidentally delete ClearCase data. In addition, we describe situations in which you may need to take measures to prevent such accidents from occurring.
When the ClearCase MVFS is active on a client host, the UNIX file system is modified so that the root directory contains itself recursively (Figure 8-1). This makes certain “recursive” pathnames valid. For example:
/view/alpha/view/beta/view/alpha/view/gamma/usr/src/lib |
This situation causes commands that traverse the entire directory tree, starting at the UNIX root directory ( / ), to loop infinitely. In particular, many UNIX systems configure the root user to have a daily crontab(1) script that performs a “cleanup” on the file system tree. If the script uses a find / command, it runs the risk of looping infinitely.
 | Note: This situation applies equally to commands and programs executed by any user, either interactively or through a script. |
The ClearCase installation script, install_release, analyzes the crontab file of the root user on a client host. It modifies entries in this file to prevent the recursive traversal problem (or displays a message warning that it cannot perform the modification).
After installation, you should verify the correctness of install_release's changes. In addition, you should modify the crontab entries of other users, according to the instructions in the next section.
Use the following procedure to analyze and, if necessary, modify all of a host's crontab entries.
Analyze the crontab entries—Determine what entries will encounter the recursion problem:
% su Password: <enter root password> # grep "find /" /usr/spool/cron/crontabs/* /usr/spool/cron/crontabs/root:15 3 * * * find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs –prune (typical output)In the example above, and throughout this section, long lines are broken for readability. In actual crontab files, each entry must be contained on a single physical text line.
Revise crontab entries—You must modify each crontab file in which an offending entry was found. For example:
# su - username (switch user identity) # crontab -l > /tmp/C (create temporary file with that user's crontab entries) # vi /tmp/C (modify those entries) # crontab < /tmp/C (configure the modified entries)
During the edit session, change the command containing find / by adding the host-appropriate options indicated by boldface below:
SunOS host—Since the viewroot directory (typically, /view) is mounted as a file system of type mvfs, use the –prune option to prevent recursion:
15 3 * * * find / -name .nfs\* -mtime +7 -exec rm -f {} ';' -o -fstype nfs -prune -o -fstype mvfs -pruneHP-UX host—No crontab entry is provided by default. The following entry searches file systems of type hfs and cdfs only (the viewroot directory is neither of these):
15 3 * * * find / -path /view -prune -o -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -pruneIRIX host—Make sure that the -local option is present, to prevent crossing of mount points. Since the viewroot directory is mounted, this prevents recursion:
0 5 * * * find / -local -type f '(' -name core -o -name dead.letter ')' -atime +7 -mtime +7 -exec rm -f '{}' ';'OSF/1 host—Make sure that the -xdev option is present, to prevent crossing of mount points. Since the viewroot directory is mounted, this prevents recursion:
15 3 * * * find filesys-1 filesys-2 ... -xdev -mtime +7 -exec rm -f {} \;
When it begins execution, the lockmgr program creates a socket, /tmp/.A/almd, through which it communicates with local and remote calling processes. To reduce the likelihood of accidental deletion, the socket is created within a subdirectory of /tmp, and is owned by the root user.
On each ClearCase host, you should examine the root user's crontab file, modifying it if necessary to ensure that the lockmgr socket is not deleted accidentally. For example, the following find command includes a “not a socket” clause:
find /tmp ! \( -type s \) -exec rm -f {} \;
|