Classic Shell Scripting - Arnold Robbins [200]
If it is possible that running a second instance of a cron job might be harmful (e.g., filesystem backups or log-file updates), you need to make sure to prevent that, either by using a suitable lock file, or by switching from cron to at and having the job submit its successor just before the job itself finishes. Of course, you then have to monitor its every run so that in the event of a failure, if you use lock files, you make sure to remove them, and if you use at, you reschedule the job.
* * *
You can remove your crontab file entirely with crontab -r. Like rm, this is irrevocable and unrecoverable. Caution suggests preserving a copy like this:
crontab -l > $HOME/.crontab.`hostname` Save the current crontab
crontab -r Remove the crontab
so that you can later restore it with:
crontab $HOME/.crontab.`hostname` Restore the saved crontab
Since there is potentially one crontab file per host, we include the hostname in the name of the saved file so we can readily identify which machine it belongs to.
crontab replaces any existing schedule with that in the file given on its command line, provided that no syntax errors are found; otherwise, the old schedule is preserved.
As with the at command, there are cron.allow and cron.deny files in system directories that control whether cron jobs are allowed, and who can run them. Complain to your system manager if you find yourself denied access to this useful facility.
* * *
[5] Different systems vary as to which of these is a system call and which is a library function.
The /proc Filesystem
Several Unix flavors have borrowed an idea developed at Bell Labs: the /proc filesystem. Instead of supplying access to kernel data via myriad system calls that need continual updating, kernel data is made available through a special device driver that implements a standard filesystem interface in the /proc directory. Each running process has a subdirectory there, named with the process number, and inside each subdirectory are various small files with kernel data. The contents of this filesystem are described in the manual pages for proc(4) (most systems) or proc(5) (GNU/Linux).
GNU/Linux has developed this idea more than most other Unix flavors, and its ps command gets all of the required process information by reading files under /proc, which you can readily verify by running a system-call trace with strace -e trace=file ps aux.
Here's an example of the process files for a text-editor session:
$ ls /proc/16521
List proc files for process 16521
cmdline environ fd mem root statm
cwd exe maps mounts stat status
$ ls -l /proc/16521
List them again, verbosely
total 0
-r--r--r-- 1 jones devel 0 Oct 28 11:38 cmdline
lrwxrwxrwx 1 jones devel 0 Oct 28 11:38 cwd -> /home/jones
-r-------- 1 jones devel 0 Oct 28 11:38 environ
lrwxrwxrwx 1 jones devel 0 Oct 28 11:38 exe -> /usr/bin/vi
dr-x------ 2 jones devel 0 Oct 28 11:38 fd
-r--r--r-- 1 jones devel 0 Oct 28 11:38 maps
-rw------- 1 jones devel 0 Oct 28 11:38 mem
-r--r--r-- 1 jones devel 0 Oct 28 11:38 mounts
lrwxrwxrwx 1 jones devel 0 Oct 28 11:38 root -> /
-r--r--r-- 1 jones devel 0 Oct 28 11:38 stat
-r--r--r-- 1 jones devel 0 Oct 28 11:38 statm
-r--r--r-- 1 jones devel 0 Oct 28 11:38 status
Notice that the files all appear to be empty, but in fact, they contain data that is supplied by the device driver when they are read: they never really exist on a storage device. Their timestamps are suspicious as well: on GNU/Linux and OSF/1 systems, they reflect the current time, but on IRIX and Solaris, they show the time that each process started.
The zero size of /proc files confuses some utilities—among them, scp and tar. You might first have to use cp to copy them elsewhere into normal files.
Let's look at one of these files:
$ cat -v /proc/16521/cmdline
Display the process command line
vi^@+273^@ch13.xml^@
The -v option causes unprintable