Hope everyone's having a great Sunday!
For today's humor post I found a nice page from Pedro Diaz' Technical University of Madrid Homepage. I've actually only included a very small portion of his page on Unix and Linux Horror Stories. The rest of it is well worth the lengthy read.
The few parts I included below are mostly humorous, but you should definitely check out The Entire Horror Stories Page. It contains a lot of mailed in information that ranges from the funny to the straight-up informational, so, while your chortling (nobody uses that word anymore - time to bring back some of the old jargon ;) you may just learn something.
Enjoy :)
*NEW*
From: samuel@cs.ubc.ca (Stephen Samuel)
Organization: University of British Columbia, Canada
Some time ago, I was editing our cron file to remove core more than a day
old. Unfortunately, thru recursing into VI sessions, I ended up saving an
intermediate (wron) version of this file with an extra '-o' in it.
find / -name core -o -atime +1 -exec /bin/rm {} \;
The cute thing about this is that it leaves ALL core files intact, and
removes any OTHER file that hasn't been accessed in the last 24 hours.
Although the script ran at 4AM, I was the first person to notice this,
in the early afternoon.. I started to get curious when I noticed that
SOME man pages were missing, while others were. Up till then, I was pleased
to see that we finally had some free disk space. Then I started to notice
the pattern.
Really unpleasant was the fact that no system backups had taken place all
summer (and this was a research lab).
The only saving grace is that most of the really active files had been
accessed in the previous day (thank god I didn't do this on a saturday).
I was also lucky that I'd used tar the previous day, as well.
I still felt sick having to tell people in the lab what happened.
-----------------------------------------------------------------------------
From: Stephen Samuel
Organization: University of British Columbia, Canada
As some older sys admins may remember, BSD 4.1 used to display unprintable
characters as a questionmark.
An unfortunate friend of mine had managed to create an executable with a
name consisting of a single DEL character, so it showed up as "?*".
He tried to remove it.
"rm ?*"
he was quite frustrated by the time he asked me for help, because
he had such a hard time getting his files restored. Every time he walked
up to a sys-admin type and explained what happened, they'd go "you did
WHAT?", he'd explain again, and they'd go into a state of uncontrolable
giggles, and he'd walk away. I only giggled controlably.
This was at a time (~star wars) when it was known to many as "the mythical
rm star".
-------------------------------------------------------------------------------
From: jjr@ctms.gwinnett.com (J.J. Reynolds)
Organization: Consolidated Traffic Management Services (CTMS)
The SCO man page for the rm command states:
It is also forbidden to remove the root directory of a given
file system.
Well, just to test it out, I one day decided to try "rm -r /" on one of our
test machines. The man page is correct, but if you read carefully, it
doesn't say anything about all of the files underneath that filesystem....--
-------------------------------------------------------------------------------
From: bcutter@pdnis.paradyne.com (Brooks Cutter)
A while back I installed System V R4 on my 386 at home for development
purposes... I was compiling programs both in my home directory, and
in /usr/local/src ... so in order to reduce unnecessary disk space I
decided to use cron to delete .o files that weren't accessed for
over a day...
I put the following command in the root cron...
find / -type f -name \*.o -atime +1 -exec /usr/bin/rm -f {} \;
(instead of putting)
find /home/bcutter -type f -name \*.o -atime +1 -exec /usr/bin/rm -f {} \;
find /usr/local/src -type f -name \*.o -atime +1 -exec /usr/bin/rm -f {} \;
The result was that a short time later I was unable to compile software.
What the first line was doing was zapping the files like /usr/lib/crt1.o
.. and later I found out all the Kernel object files...
OOPS! After this happened a second time (after re-installing the files
from tape) I tracked down the offending line and fixed it....
Yet another case of creating work by trying to avoid extra work (in this
case a second find line)
, Mike
Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.
