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
rjg@sialis.mn.org (Robert J. Granvin) (06/04/89)
>> 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. ?? /usr/spool/uucppublic is not a required nor integral part of the system, filesystem, file structure or even UUCP. Any directory, anywhere, given the proper permissions, can replace /usr/spool/uucppublic, provided that the neighbor sites are aware of it. /usr/spool/uucppublic is a "publicly available" directory that allows neighbor sites to deliver or retrieve files. News and mail do not travel through or use this directory. /usr/spool/uucppublic was created so as to have a nice, central, globally known "Standard" location for such file transfers. You can be generally assured that /usr/spool/uucppublic exists on any machine. However, should it be gone, the worst that will happen is that the remote machine will get an ACCESS DENIED message back from uucp on the host machine. No file system errors, no file structure destructions, etc. If you don't have uucp installed, you won't even have this directory to start with. /usr/spool/uucp, however, is more important, but again, has no effect on the filesystem or file structure, if it were missing. / is more of an issue... :-) > 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. This is the way it is intended and supposed to be. Never run things from root that aren't necessary. If your permissions and ownerships are set correctly, root will not be necessary for cleaning up uucp. -- ________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"
karl@mstar.MorningStar.COM (Karl Fox) (06/04/89)
In article <1526@sialis.mn.org> rjg@sialis.mn.org (Robert J. Granvin) writes: >>> 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. > >?? > >/usr/spool/uucppublic is not a required nor integral part of the >system, filesystem, file structure or even UUCP. What Tom was pointing out is that if /usr/spool/uucppublic isn't there, then the 'cd' will fail, leaving the 'find' running in '/'. Not a nice idea at all -- this is a NASTY bug. -- Karl Fox, Morning Star Technologies karl@MorningStar.COM
rjg@sialis.mn.org (Robert J. Granvin) (06/04/89)
I write, in response... >>> 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. > >?? > >/usr/spool/uucppublic is not a required nor integral part of the >system, filesystem, file structure or even UUCP. Bleah. I'll admit two things... 1/ The previous article was not written clearly. The specific problem was not actually mentioned (or made clear), however 2/ I did not consider the situation close enough. As was pointed out to me: Bob, he didn't say it explicitly but I think his point was that if the `cd` failed, the `find` could run on whatever the current directory is. If this is "/", then everything older than 30 days which the script's permissions can delete is gone...if run as root then ____. >> 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. > >This is the way it is intended and supposed to be. Never run things >from root that aren't necessary. If your permissions and ownerships >are set correctly, root will not be necessary for cleaning up uucp. The original points were actually correct. But to add onto it, many of you will notice that / has permissions of 777. Even a misfed cron as uucp might cause serious damage. Running as uucp instead of root would do little to contain the damage. (This applies elsewhere as well). Fortunately however, for this example, the damage would _probably_ be contained to just uucp and related directories. But that's by no means guaranteed. -- ________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"
levy@cbnewsc.ATT.COM (Daniel R. Levy) (06/04/89)
< >>> 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.
[ presumably because the cd will fail, leaving the current directory to be / ]
Under Bourne shell (/bin/sh), if cd fails the script aborts with an
error message. Presumably, cron is using /bin/sh, so even if there
is no /usr/spool/uucppublic the cron entry won't trash the disk starting
from /.
(Note, however, that a failed cd will NOT abort a script running under ksh.
I have been bitten by that one because ksh runs script commands invoked
from it with another ksh, and some sh scripts depend upon a script
aborting upon a failed cd rather than blithely plunging on with nothing
more than an error message.)
--
Daniel R. Levy UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!levy
AT&T Bell Laboratories
5555 West Touhy Avenue Any opinions expressed in the message above are
Skokie, Illinois 60077 mine, and not necessarily AT&T's.hjespersen@trillium.waterloo.edu (06/05/89)
>>> cd /usr/spool/uucppublic >>> find . -type f -mtime +30 -exec rm -f {} \; Ok, maybe I haven't been following this discussion closely enough but what is wrong with find /usr/spool/uucppublic -type f -mtime +30 -exec rm -f {} \; -- Hans Jespersen hjespersen@trillium.waterloo.edu uunet!watmath!trillium!hjespersen
dave@galaxia.Newport.RI.US (David H. Brierley) (06/05/89)
In article <1526@sialis.mn.org> rjg@sialis.mn.org (Robert J. Granvin) writes: >>> 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. > >/usr/spool/uucppublic is not a required nor integral part of the >system, filesystem, file structure or even UUCP. You are missing the point. If you execute a 'cd' command to a directory that does not exist the only thing that happens is that you get a stupid little error message. If your current directory is '/', which is normally the case for the 'smgr' process, and you execute the two commands listed above, and for some reason the 'cd' command fails, this will have the effect of wiping out every file on your machine which has not been modified within the last 30 days. When was the last time you modified /unix? How about the various files in /bin or /usr/bin? These two commands could be potentially disastrous even if they are run as 'uucp' instead of 'root'. When was the last time you modified the files /usr/bin/uucp, /usr/bin/uux, and /usr/lib/uucp/uucico? -- David H. Brierley Home: dave@galaxia.Newport.RI.US {rayssd,xanth,lazlo,mirror}!galaxia!dave Work: dhb@rayssd.ray.com {sun,decuac,gatech,necntc,ukma}!rayssd!dhb
levy@cbnewsc.ATT.COM (Daniel R. Levy) (06/05/89)
In article <694@galaxia.Newport.RI.US>, dave@galaxia.Newport.RI.US (David H. Brierley) writes:
< >>> cd /usr/spool/uucppublic
< >>> find . -type f -mtime +30 -exec rm -f {} \;
< If you execute a 'cd' command to a directory that
< does not exist the only thing that happens is that you get a stupid little
< error message. If your current directory is '/', which is normally the case
< for the 'smgr' process, and you execute the two commands listed above, and
< for some reason the 'cd' command fails, this will have the effect of wiping out
< every file on your machine which has not been modified within the last 30 days.
This only happens if the commands are entered into an interactive shell session.
If they are in a script being run by /bin/sh, a "cd" that fails will abort the
script (O.K., will abort the shell running the script). Korn shell (/bin/ksh)
will not abort, however, on a failed cd in a script. This is a feature to
permit recovery from inability to cd somewhere but for the unwary script-writer
it can cause trouble like the above....
--
Daniel R. Levy UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!levy
AT&T Bell Laboratories
5555 West Touhy Avenue Any opinions expressed in the message above are
Skokie, Illinois 60077 mine, and not necessarily AT&T's.jbm@uncle.UUCP (John B. Milton) (06/05/89)
In article <14271@watdragon.waterloo.edu> hjespersen@trillium.waterloo.edu () writes: > > >>> cd /usr/spool/uucppublic > >>> find . -type f -mtime +30 -exec rm -f {} \; > >Ok, maybe I haven't been following this discussion closely enough >but what is wrong with > > find /usr/spool/uucppublic -type f -mtime +30 -exec rm -f {} \; Nothing, except I would make it: find /usr/spool/uucppublic -type f -mtime +30 -print | xargs rm -f John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
les@chinet.chi.il.us (Leslie Mikesell) (06/06/89)
In article <536@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: >Nothing, except I would make it: >find /usr/spool/uucppublic -type f -mtime +30 -print | xargs rm -f Not if you have a stock 3B1 without the development stuff, because you wouldn't have xargs. I wonder who decided xargs was a development tool. Les Mikesell
arnold@skeeve.UUCP (Arnold D. Robbins) (06/06/89)
In article <8640@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Not if you have a stock 3B1 without the development stuff, because >you wouldn't have xargs. I wonder who decided xargs was a development tool. Probably the same bozo who decided that 'vi' was. You really have to wonder sometimes about the people doing Unix at AT&T (outside the research labs). -- "Crack-pot societies of all kinds sprang up everwhere, advocating everything from absolutism to anarchy. Queer cults arose, preaching free love, the imminent end of the world, and many other departures from the norm of thought." E.E. "Doc" Smith, Children of the Lens, 1954 | Arnold Robbins, skeeve!arnold
rjg@sialis.mn.org (Robert J. Granvin) (06/07/89)
>You really have to wonder sometimes about the people doing Unix at AT&T >(outside the research labs). Don't blame AT&T for everything... remember that Convergent had a (Big) hand in the hardware, software and packaging of the 3b1/7300... -- ________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"
jbm@uncle.UUCP (John B. Milton) (06/07/89)
In article <8640@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <536@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: > >>Nothing, except I would make it: > >>find /usr/spool/uucppublic -type f -mtime +30 -print | xargs rm -f > >Not if you have a stock 3B1 without the development stuff, because >you wouldn't have xargs. I wonder who decided xargs was a development >tool. OUCH! I had no idea! I better clean up my xxargs and post it right away. I didn't even check to see if had been split off. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:466-9324; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
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 ]
dold@mitisft.Convergent.COM (Clarence Dold) (06/07/89)
in article <1538@sialis.mn.org>, rjg@sialis.mn.org (Robert J. Granvin) says: > >>You really have to wonder sometimes about the people doing Unix at AT&T >>(outside the research labs). > > Don't blame AT&T for everything... remember that Convergent had a > (Big) hand in the hardware, software and packaging of the 3b1/7300... > Scratch that thought, please. The Safari 4 was designed and packaged under very close direction from AT&T. No other Convergent product has the software unbundling of the PC7300. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 434-5293 ...pyramid!ctnews!tsmiti!dold P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007
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"
rjg@sialis.mn.org (Robert J. Granvin) (06/09/89)
>> Don't blame AT&T for everything... remember that Convergent had a >> (Big) hand in the hardware, software and packaging of the 3b1/7300... >> >Scratch that thought, please. >The Safari 4 was designed and packaged under very close direction from AT&T. >No other Convergent product has the software unbundling of the PC7300. As it was described to me, by some long ago Safari 4 involvee, the Safari 4 was designed by Convergent, and purchased by AT&T following the general completion of the product. The OS (original) was a port of a Convergent port (I forget the actual one) which of course originated from original AT&T code. Since that time, AT&T marketed the machine and continued to modify the original Convergent port of a Convergent port of AT&T code. :-) Even from Convergent, you cannot claim that Convergent produced all the successes of the machine, while AT&T produced all of the failures. My point, originally, was not that Convergent should be blamed for anything, but that any failures or lacks of the machine are not necessarily solely AT&T's "fault". (Of course, some of those are purely expectation, since the machine was perhaps not intended to do what you want to do with it). AT&T wasn't the lone player in this machine. -- ________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