thad@cup.portal.com (Thad P Floryan) (06/02/89)
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 ]tneff@bfmny0.UUCP (Tom Neff) (06/03/89)
In article <19071@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > #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 {} \; This is dangerous if run as root. If anything - disk error, anything - happens to make /usr/spool/uucppublic unavailable, you will wipe your file structure. There are three things one can do - not mutually exclusive. 1) Trap the cd failure as follows - cd /usr/spool/uucppublic || exit 1 2) Perform the find explicitly rather than relatively: find /usr/spool/uucppublic -type f -mtime ... etc etc 3) Safest of all, and what I do - put this stuff in uucp's cron rather than root's at all. It's also OK to let the root cron entry do an 'su uucp' first. The best thing to do, and what I'll do tomorrow after reading the AQA, is add (2) to (3). This may render the 'cd' irrelevant but who cares. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET
thad@cup.portal.com (Thad P Floryan) (06/07/89)
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 when they read my posting, 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. 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. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
bud@alba2l.UUCP (Alex Batyi) (06/08/89)
In article <19196@cup.portal.com>, thad@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@alba2l.UUCP Alba Tool Co., Inc. 933 Washington Ave. Croydon, PA 19020 --=={ Manufacturer of single and multi-spindle screw machine products. }==--
ignatz@chinet.chi.il.us (Dave Ihnat) (06/09/89)
In article <19196@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >One person threatens to sue AT&T. Fat chance; read the disclaimer notices in the software. Yeah, they can still sue, but they first have to break the agreement. Don't know if they can, but AT&T *does* have one helluva lot of lawyers left over after the divestiture battles... Dave Ihnat Analysts}i International Corp. aicchi!ignatz || ignatz@homebru.chi.il.us
rjg@sialis.mn.org (Robert J. Granvin) (06/09/89)
>From private email I've received, a LOT of people's stomachs sunk to the floor >when they read my posting, 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. Lawsuits are fun. Especially when you don't have a legal foot to stand on. I'm curious... On what grounds would such a lawsuit be made? AT&T warrants that their software operates. It doesn't warrant that it operates well or even correctly. By the way, this is the same way that everyone warrants their software (read between the lines, you'll see that the only time a warranty really falls apart is that if it doesn't work at all). The warranty is then amended with the disclaimer that the distributor, author, producer or whoever else has their fingers in it, does not warrant the software to be suitable for any specific purpose, and (an important one here) that they are not liable for any damage that arises from the use or inability to use said software. When you break all this down, you find that the source is only liable to guarantee that the product works as advertised. Beyond that, you take full responsibility for it. If the software fails, it is not necessarily the manufacturers liability, since you agreed to the risk of using it. By utilizing group and user permissions even minimally, you can protect yourself very well from rampant processes and even other users. This shouldn't be the alternative to solving any problem, but it should also be utilized in general just for general safety and minimal security. While if something goes bonkers you may have to reload some system software, but your own software is probably secure. >The point being: the "stock" uudemon.day is reprehensible and irresponsible I wouldn't go to that extreme. If so, then a _lot_ of software also must be called reprehensible and irresponsible. Stock uudemon.day makes a simple assumption that can, but almost never, fails. The chances of you being bitten by it are pretty slim to none. Of course, you wouldn't want to be the statistic... :-) However, I again bring up the point: uudemon.day is and SHOULD be run by uucp. There are very few files on the system that can be deleted by uucp, in general. This isn't to say that any damage would be minor or unnoticeable, however. On the other hand, a person should never make the assumption that running such a thing as root is a good idea. >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. I think we've sufficiently beaten this into the ground enough. The solution is VERY simple. Remove the `cd`, and make the find reference an explicit path. If the directory dies or goes away, the find will fail, and nothing more will happen than your uucp mailfile getting a note of the failure. -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg "Exxon: Our gasoline contains no sea water"
thad@cup.portal.com (Thad P Floryan) (06/13/89)
I'll keep this short since it seems evident that everyone is NOW apprised they should examine crontab's hellspawns! :-) From re-reading the original email, it appears the threat of suing AT&T was figurative and not literal; a statement made in the heat of the moment of discovering all one's uucp transfers were relegated to the Great Bit Bucket In The Sky. Hey! I was angry, too. At least I had disciplined myself to maintain a regular backup policy, so nothing was truly lost on my system. but that ``uudemon.day'' script is definitely a "gotcha." I'm replacing the Miniscribe 6085 with a Maxtor XT2190 asap, for 80+ more MB. The final point: a forum such as this newgroup DOES benefit people who read others' discoveries and tips. From one misfortune, EVERYONE benefits. Free and unfettered communication is a win-win situation! Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
tkacik@rphroy.UUCP (Tom Tkacik) (06/14/89)
In article <19425@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >I'll keep this short since it seems evident that everyone is NOW apprised >they should examine crontab's hellspawns! :-) > >but that ``uudemon.day'' script is definitely a "gotcha." > >The final point: a forum such as this newgroup DOES benefit people who read >others' discoveries and tips. From one misfortune, EVERYONE benefits. The uudemon.[hour,day,week] files are listed in the Nutshell handbook for Managing UUCP and USENET. They are identical to the ones on the UNIXPC. This is not a problem with the UNIXPC, but probably with all UNIX Sys V machines. --- Tom Tkacik GM Research Labs, Warren MI 48090 uunet!edsews!rphroy!megatron!tkacik "If you can't stand the bugs, stay out of the roach-motel." Ron Guilmette