crontab Daemon-from-Hell

Alex Batyi bud at alba2l.UUCP
Thu Jun 8 23:26:00 AEST 1989


In article <19196 at cup.portal.com>, thad at cup.portal.com (Thad P Floryan) writes:
> Re: Tom Neff's comments about my "discovery" ...
> The "stock" crontab distributed with the UNIXPC contains this line:
> 0 4 * * * /bin/su uucpadm % /usr/lib/uucp/uudemon.day > /dev/null
> and the "stock" /usr/lib/uucp/uudemon.day script contains the "find" that
> deletes aged files.
> From private email I've received, a LOT of people's stomachs sunk to the floor
[white space deleted...]

	Gee, I thought everybody KNEW about that. B->  Maybe you should
also know that it traverses the whole tree for files named core.  Read
ALL of the shell scripts mentioned in the system crontab files, and the
/etc/rc.d directory has scripts,... wait....  

/etc/rc.d:
total 4
-r--r--r--   1 root     sys          134 Nov 20  1988 cron
-rwxr-xr-x   1 root     sys          134 Jun  4 00:00 lpstartsched
-r--r--r--   1 root     sys          197 Mar 17  1986 setcolor.rc
-r--r--r--   1 root     sys           57 Nov 20  1988 uucp

...has scripts that execute on powerup, and scripts below (i'm sure you've
read /etc/inittab) get executed when going to the init state indicated by
the digit at the end of their respective names.

-rwxr--r--   1 root     sys          292 Nov 20  1988 /etc/rc0
-rwxr--r--   1 root     sys          730 Nov 20  1988 /etc/rc2

BTW, uuto and (I think) uupick are also shell scripts and a good source for
ideas on possible modifications to the various uudemons.

Disclaimer: I have never seen a Unixpc that I know about except subliminal
sightings in cases where I saw a movie known to have one sitting on a desk.
Your system COULD have binarys for some functions. (I doubt it for most)

The scripts are/should be marked "unpublished", however they are a thorough
education in slick shell programming.  Oh speaking of slick!  Read the lp
interface for the dumb serial printer.  Finding it is an exercise for the
reader.     

> [...], and they quickly discovered that a lot of files have
> been deleted by the "stock" uudemon.day script.  One person threatens to
> sue AT&T.

hmmm... Sue AT&T, one person?,... hmmm... <muffled snicker> $$$$$$$$$

> The point being: the "stock" uudemon.day is reprehensible and irresponsible
> by not warning about pending deletion; my solution was an addition to
> uudemon.day that provides advance warning of the pending doom.  Variations on
> my original proposal include sending mail, but I still prefer my solution
> since EVERYONE (among the user community of a given system) is apprised of the
> situation and will be alerted to take action before it's too late.

WARNING! Personal opinion follows (Not ROT13!) hit 'n' now if offended
by others personal opinions! :-)

These are ALL good ideas and I'm suprised AT&T didn't think of them.
Perhaps they did and chose silent deletion internally after experimentation
with the possible alternatives.  We tend to junk up file systems through
neglect, spool directories are sometimes separate file systems to keep
from blowing /dev/root on an overload.  After a while with the default
arrangement you tend to get things out of uucppublic quicker :-)
This reduces the possibility of losing files should /usr/spool run out of
free space or inodes.   -alex
-- 
	AJB                    +1 215 788 5957          [...!bpa!]alba2l!bud
        Quote:"If you lose your memory, forget it!"           bud at alba2l.UUCP
         Alba Tool Co., Inc.  933 Washington Ave.  Croydon, PA  19020
 --=={ Manufacturer of single and multi-spindle screw machine products. }==--



More information about the Comp.sys.att mailing list