Mostly Harmless

D'you want -r with that?

Some vintage (thankfully) goofs in no particular order and not all by me. There is nothing like the curious abdominal tingle which accompanies the dawning realisation that an rm command has broken free of its moorings...

1. All C'ed up

This is my favourite, probably because it is another class of unconscious assumption.

I had just commented a large number of C source files and then moved on from that to edit a Bourne shell script to be run as root. One of the lines I added was:

rm /tmp/scratch$$.*       /* Clean up scratch files */

This was such a narrow escape! There are almost no interesting regular files in "/". The main thing to put back on that machine was the symlink from /bin to /usr/bin, without which all of the shell scripts beginning "#!/bin/sh" cannot work.

Still, the error message rm: Clean: no such file or directory was enough to kick off the old rm frissance.

2. Dotty

The need to remove several large source trees accessible only by superuser and sitting below directories with names like: .old .070996 .arch etc, led me (one fateful evening) to type:

rm -rf .*

just above them. I feel clammy just thinking about it.

The trees were very large so it did not concern me that this command had not returned after some minutes - but slowly I became aware that all was not well... It didn't help that this machine was in a kind of cluster with several others - each of which shared its entire filesystem via amd mountpoints with root allow privs.

It was a long night...

3. Cron only too HTH

A customer complained that his machine had hung and then corrupted huge chunks of /usr when he forced a panic. He submitted a manifest of what was left in /usr as evidence.

We already had an idea that there was some rm-ery afoot and asked him to check what the machine had been doing at the time. Following a hunch I took the source of rm and made a modified version which output file names instead of unlinking them and ran it on a local system with the same Solaris release.

The rationale was that rm's file walk removes files and descends directories in directory entry order. Since most of the files in /usr are put there during installation and never subsequently deleted this file walk will tend to be the same on machines installed with the same release. I split the output of my "neutered" rm at ld.so.1, whose removal probably hung the machine. The remaining list of files was an almost exact match with the manifest supplied by the customer...

... who, in the meantime, had found a root cronjob which did something like:

cd $SCRATCHDIR
rm -rf *

This is a well known danger spot. One should guard against the possibilities of $SCRATCHDIR being either null or not something that one could cd to.

4. Death by wrapper

Many years ago a friend of mine became so concerned by his propensity for causing collateral damage with rm that he aliased it to rm -i. I have since encountered whole sites where this lunacy is standard practice.

The funny thing in the case of my friend was the speed with which the inevitable disaster overtook him. I think it was mere days before he typed rm * on some machine or other, expecting the friendly dialogue but getting only a prompt and a directory more echoey than he had intended.

Thurber in The Bear Who Could Let It Alone concludes "It is better to fall flat on your face than lean too far backward".

Posted at 10:59PM Apr 03, 2007 by John Alderson in Code  |  Comments[3]