I came across this yesterday and thought it might bring a smile to
people's faces ...:)
Wesley Parish
Begin forwarded message:
From: A. P. Garcia a.phillip.gar...@gmail.com
Date: 11 October 2012 4:31:43 AM
To: t...@tuhs.org
Subject: [TUHS] unix horror stories
i happened across this cute document in my archives...
*nabblisa-announce-ow...@cs.umb.eduTue Dec 28 14:10:50 1993
*tobblisa-annou...@cs.umb.edu
*suSome notes from December 1, 1993 meeting
*frJohn P. Rouillard rou...@terminus.cs.umb.edu
*sebblisa-announce-ow...@cs.umb.edu
*daTue, 28 Dec 1993 12:42:01 -0500
*mi199312281742.aa17...@cs.umb.edu
*refrom cs.umb.edu (dae...@cs.umb.edu [158.121.104.2])
by argali.opal.com (8.6.4/jr2.9) with SMTP
id OAA27752; Tue, 28 Dec 1993 14:10:43 -0500
*reby cs.umb.edu id AA18007
(5.65c/IDA-1.4.4 for bblisa-announce-outgoing); Tue, 28 Dec
1993 12:42:08 -0500
*refrom terminus.cs.umb.edu by cs.umb.edu with SMTP id AA17997
(5.65c/IDA-1.4.4 for bblisa-annou...@cs.umb.edu); Tue, 28 Dec
1993 12:42:01 -0500
*exPrecedence: bulk
*tx
Here are the notes from the December 1, 1993 meeting. Names have been
deleted to protect the innocent. The topic was:
UNIX Horror Stories (Actually Computer Horror Stories)
and away we go.
Story 1:
A new user I knew was trying to clean out some old accounts on a
system
he was given. As root, he changed directories to one of the old user
directories, and then did 'rm -r *' but noticed it left a directory
called .X11 behind. To get rid of it, and to be sure it wouldn't
fail,
he did 'rm -rf .*'. Sad to say he didn't realize that '.*' could and
would expand into '..', and it would continue to do so recursively.
I thought this was better than the 'garden variety' 'rm -rf' scenario.
The guy though, worst case, he'd blow away the old user accounts,
but got the entire disk instead!
Needless to say, it was time for the install disketts (yes, diskettes,
about 30 of them...).
Story 2:
SunOS 4.0 NFS server configured with IP address 192.9.200.0
by suninstall (default - a suninstall bug) and rebooted after
OS installation... (nice DECnet meltdown)
Story 3:
/etc/reboot - then noticing you were in the wrong window...
Story 4:
Coming in at 7:00AM Saturday to upgrade to Ultrix 2.2, then
5 hours later having the other guy type in rm -rf - then
realising he forgot to cd out of /etc...
Story 5:
Having a user request some files to be restored - but forgetting
when they existed except that it was sometime around a
year or so ago...
Story 6:
Would you all be interested in the time a workman disassembled the
cubicle
containing my NIS master and dropped a 1.3 gig disk several feet to
the
floor ...? (Prior to telling me he was taking it apart of course ...)
Story 7:
talking to an end-user who just called in over the phone
my root filesystem filled up, so I looked around; I found
removed vmunix
and boot, and that seems to have fixed things, so I typed fastboot.
Story 8:
Back in the days when UNIX V6 was new, we installed it on a PDP 11/44
in the CS lab. It ran fine. We allowed students on it. It ran fine.
People started using it for real work, albeit tentatively. It ran
fine.
It was a bit slow if several people were on -- what do you expect for
a PDP11/44 -- but, it ran fine.
Then occasioanlly, we started noticing that troff would go wrong and
it would mis-format some portions of a document. Funnily enough,
when you re-ran the job, it ran fine. We opened up the CAT. Have
you ever been inside a CAT? These were serious phototypesetters.
And, we could find nothing wrong with ours. After a few days of
frustratedly looking for problems with the CAT, and the wiring, and
the troff config, it seemed to start working OK again, so we closed
it all up, and forgot about the problem.
About 12 weeks later, students working on simulation class assignments
started complaining that if they came in and ran their programs during
the day, the programs would give the wrong results. But, if they ran
the SAME programs in the evening, they'd be fine. Thinking to
ourselves
that students are a real pain in the ass, we took a look. Thing is,
they were right. The programs DID indeed give different results
depending on when you ran them. Mostly, they were OK, but occasional
daytime runs were flaky. Problem with the core (yes, we had core
storage on that system)? We swapped core boards. No change. We
swapped CPU boards. No change. We practically swapped every board
and the bus and built a new machine. No change. Of course, the
number of failures were few -- the programs ran OK MOST of the time,
so pinning this down was a slow process. Eventually, the students
all got their assignments done, and they went on to other exercises,
and we didn't have any more problems, so we got on with our lives,
and forgot about it.
Another 12 weeks go by. We were all happy. Life was good. The 11/44
is still running
