Xref: utzoo unix-pc.general:2974 comp.sys.att:6594
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!sun!imagen!atari!portal!cup.portal.com!thad
From: thad@cup.portal.com (Thad P Floryan)
Newsgroups: unix-pc.general,comp.sys.att
Subject: crontab Daemon-from-Hell
Message-ID: <19071@cup.portal.com>
Date: 2 Jun 89 10:57:39 GMT
Organization: The Portal System (TM)
Lines: 121

As Robin would say: "Holy Bat Guano, Batman!"

The words *I* used aren't suitable for public distribution.   :-)

To begin a sad tale of woe ...

Two days ago I suddenly noticed an unusual flurry of disk activity and, for
a moment, I was elated when I suddenly had enough free disk space to do that
compile I've been putting off.  Then it dawned on me: WHERE did that disk
space come from?

Uh oh.

A quick check of /usr/adm/unix.log revealed nothing.  The only obvious culprit
was cron (or smgr on the UNIXPC).  A perusal of /usr/lib/crontab indicated that
/usr/lib/uucp/uudemon.day is scheduled to run at about the time I heard the
bits fly off the disk.

For the first time in over 2 years I finally looked at uudemon.day and was
horrified at what I saw: the last line {DELETES | REMOVES | PURGES | EXPUNGES}
aged files in the uucp spool directories, and the deletion is NOT retractable
nor is any record kept nor any user notified of the dastardly deed.  Sheesh.

To illustrate my discovery, the first 2 and last 2 lines are reproduced for
your enjoyment below (of the file /usr/lib/uucp/uudemon.day):

	#sccs	"@(#)uucp:uudemon.day	1.1"
	# 'perform once per day at 0400 hours'
		.
		.
	cd /usr/spool/uucppublic
	find . -type f -mtime +30 -exec rm -f {} \;

What this means is that all the files I'd uucp'd and let linger in the spool
directory for 30 (or more) days had vanished from disk.  :-(

Lucky for me, I maintain a regular incremental backup policy and was able to
recover the files from tape without much loss of time.  The files are NOW
languishing in a UUCP-HOLD/ directory in a non-spool path.

I quickly vowed to NEVER, EVER let this happen again, and I've developed a
simple one-line addition for the uudemon.day script that will give 10 days
warning before deletion; feel welcome to adapt it to your needs.

The 10-day warning is two-fold:

1) the ``[!!]'' error icon will appear in the screen's title bar between the
   date-and-time display and the ``[W]'' icon, and
2) a system-error window will pop-up for EACH and EVERY file for every click
   on the error icon; this window will display the COMPLETE path to the file
   destined for deletion and warn "MOVE IT OR LOSE IT!"

The warning will be repeated every day for every file until either the file(s)
are moved or deleted.  And, note, the error icon will appear on the screen for
ALL users and even if no-one is logged on; the point being to alert someone to
take action before it's too late.

The line to add between the "cd" and the "find" is:

HERE=`pwd`;find $HERE -type f -mtime +20 -exec echo {} "\nis scheduled for \
deletion in less than\n10 days by /usr/lib/uucp/uudemon.day\nunder crontab \
control\n\nMOVE IT OR LOSE IT!" > /dev/error \;

This "line" operates with either sh or ksh, so it WILL work on your system.

The use of $HERE is necessary, else the warning will display only a relative
path such as "./foofile" instead of "/usr/spool/uucppublic/xxx/yyy/foofile".

Your modified /usr/lib/uucp/uudemon.day file should now appear like:

#sccs	"@(#)uucp:uudemon.day	1.1"
# 'perform once per day at 0400 hours'
	.
	.
cd /usr/spool/uucppublic
HERE=`pwd`;find $HERE -type f -mtime +20 -exec echo {} "\nis scheduled for \
deletion in less than\n10 days by /usr/lib/uucp/uudemon.day\nunder crontab \
control\n\nMOVE IT OR LOSE IT!" > /dev/error \;
find . -type f -mtime +30 -exec rm -f {} \;


And, in closing, I'd like to pass on another tip that greatly eased my
recovery of the deleted files:

	ALWAYS make your uucp requests from a shell script, annotate the
	script with a comment about the date, and append all such scripts
	to a "master" file so you have a record of what was uucp'd and
	when (the detailed log files and ANY other extraneous files in
	the /usr/spool/uucp directory are deleted on a regular basis by
	another crontab-specified script, so do NOT save your master uucp
	script file there).

For example, I create a doit[n] file for an evening's requests in the form:

	#
	#	2-June-1989
	#
	uucp -m foobar!~/stuff/good   ~/foobar/
	uucp -m foobar!~/stuff/better ~/foobar/
	uucp -m foobar!~/stuff/best   ~/foobar/

invoke it by:

	ksh> sh doit      # or sh doit1  (OR)  sh doit2  ...

and after receiving mail notification of a successful transfer, append
the doit<n> file to the "master" for "that" system per:

	ksh> cat foobar.files doit* > holdme
	ksh> cp holdme foobar.files
	ksh> rm holdme doit*

and NOW (yeah, I learn quickly! :-) finish with:

	ksh> mv /usr/spool/uucppublic/foobar/*   ~/UUCP-HOLD/foobar/

I hope these anecdotes and notes save you some grief; it's NO fun having
files pulled out from under oneself and tossed out the window and over the
fence by the crontab Daemon-from-Hell!   :-)

Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]