Biggest command-line mistake? [closed]

Question

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here.

More info: http://serverfault.com/faq

---

What is the most damage (of whatever kind) that you have ever caused with a single mistaken/mistyped/misguided command line? I deleted a production system database by mistake a while back, for example, but I was lucky (i.e. backed-up) and there was no permanent data loss, lost money, property damage etc.

Most importantly (for votes), what do you do to make sure it will not ever happen again?

Answer 1

In SQL server, on a production system:

update customer set password = '' <enter>

The most recent backup was like a week old.

To mitigate this, I now usually write a select statement first to make sure I've got the where clause correct, then go back and edit it to insert the set clause and change the statement to update.

Answer 2

Biggest mistake? Thinking I had set two variables when I had not. So rm -rf $VARIABLE/$VARIABLE2 became rm -rf /. FreeBSD has recently updated their rm tool so that rm -rf / is not possible anymore precisely because of this mistake!

Answer 3

shutdown -h now

meant for the local workstation, but typed it while logged via ssh on production server. Since then I always have hostname in my $PS1.

Answer 4

On a VMS system, I had been using the ASSIGN DCL command to assign logical names, and I wanted to RECALL a previous ASSIGN command line. Now, in VMS, you only typed as many characters of a command to make it unambiguous. So I intended to type

REC ASS

but I accidentally typed

REQ ASS

instead. REQ was sufficiently unambigous for the REQUEST command, which broadcasts the argument to everyone with operator privs (which was everyone in IT). So the entire department received my broadcast message which was simply "ASS".

Answer 5

On a Solaris system: "killall dataLoader".

'dataLoader' was an app I was working on. On Linux, killall works like pkill. It sends a signal to processes that match a string given as the argument. On Solaris, killall trys to kill everything on the system the current user can kill. I was root.

Answer 6

Omitting the -r from a shutdown command. On a remote server. On the other side of the country. With no IT staff in the remote office.

We've all done it, it's almost like a rite of passage at this stage.

Answer 7

Trying to change ownership of everything in a directory, including dot files, with:

chown -R user * .*

Guess what that does?

Answer 8

Once, many many moons ago, I needed to find a particular executable but couldn't remember the complete name of it (but could remember a few of the letters). So I figured I'd check the /usr/bin directory with something like this

rm /usr/bin/i*g*

Strange. Nothing returned. Figuring I just had misremembered the second letter, I tried again with

rm /usr/bin/i*

Again, nothing. After doing the same with /usr/local/bin, /usr/sbin, and anything else I figured it might be in, I realized I'd been mistyping the 'ls' command.

Don't quite know where the brainfart came from, but it's definitely not a mistake I ever made again.

Answer 9

setup.exe

It was Windows Vista.

Answer 10

Meant to destroy /dev/sdb, fortunately I had a good up-to-date backup

dd if=/dev/urandom of=/dev/sda

Answer 11

select * from <File1> join <file2>

On a production box. Note the lack of an on clause. :-) Both tables were multi-million row tables, and this was on an AS/400 in the mid 90s where once the SQL was running you couldn't kill it.

Answer 12

On one of our data production server, one of my roots typed:

chmod -R 777 /

Because he was getting permissions error with some scripts...

Shortly after that, his private key was removed from all servers and he took care of the 1TB data restore on the data production server...

Answer 13

My erm favorite was when I was at university. I was building an application (I don't recall what) and as I wasn't root I had built it with

PREFIX=~username/usr/local

So I could install it to my home directory. Unfortunately it installed into

/home/username/src/app/~username/usr/local

instead. Naturally to delete it as start again i executed

rm -rf ~username

In the source directory.

I wondered why it was taking so long....

:-)

However my worst one was when I was working with a solaris workstation and after getting it all setup we wanted to wipe the configuration ready for live config. So I executed

sys-unconfig

Agreed to the warning message and instead of the machine rebooting and going back to "factory defaults" The xterm window simply said

connection closed by foreign host.

Moral of the story Don't ever leave a root shell open on another host! EVER!!

Answer 14

I once wanted to delete a bunch of files in a directory.

del *.*

The computer then said "Are you sure? [y/N]" I thought "OF COURSE I'm sure, I wouldn't have typed the darn command in otherwise! Sheesh stupid computers grumble..."

Y <enter>

C:\Windows>_

Um... WTF? Did I just erase my windows directory?....

undelete *.*

In those days of small hard disks I knew what every file in c:\windows was for and what its name was, but even after undeleting everything the system was never the same. I gained a little bit of respect for the "are you sure" prompt. Just a little.

Answer 15

Many years ago I was at home coding up some stuff in php while working on a project with a buddy of mine who was the maintainer of the project. We were IM'ing one another in a collaboration effort. We always banter back and forth in play.

I was trying to get ssh-agent to work properly on my machine while we were having a religious war of Perl vs PHP. Then I mentioned something about ssh-agent needing to be eval'ed (not sure why I said that). So then he sent me this message in an effort, so I thought, to help me with my problem (bear in mind that I was su -'ed to root):

\# eval $(echo ssh-agent | 
perl -pe 's/h-a/m -r/' | 
perl -pe 's/^ss/r/' | 
perl -pe 's/gent/f \//')

WARNING! DO NOT RUN THAT COMMAND!!!

IF you remove the eval and run the inner command by itself it is:

rm -rf /

It took me all of 4 seconds to notice what was happening but the damage was already done. I had to reinstall my OS. Fortunately, nothing of my work was wiped out except some stuff in /etc iirc. He had a HUGE laugh when I sent him a message of horror asking why he did that. We are both long-term systems engineers. He didn't think I would run it and would be more careful to check it before simply c&p'ing and I just trusted him so I didn't even consider he was playing around. Needless to say, this little story comes up all the time between us. So, I decided to immortalize it.

How have I mitigated this from happening again? I trust no-one!

Another less interesting story is a couple of years back I was doing some work on a mission critical box at work. I had a few terms open to different machine. I needed to remove some superfluous stuff in a directory. Well, I got lost in my terms and accidentally rm'ed . in my local dir but on the wrong host (wrong term)!!. I executed the command in /var/lib/mysql instead of /tmp on the application server (different term). Needless to say, I wiped out the production database. Fortunately, we had a warm standby that we flipped to while me and a co-worker rebuilt the primary from backups and the standby. That took about 18 hours to do.

Mitigation: more careful about what windows I execute commands in before executing them.

Answer 16

First of two...

On a Solaris box we had a tar backup of an AIX machine..

One of the Developers typed:

tax xvf AIX_Backup.tar

Of course the paths in the tax were absolute and we ended up making a new distro of unix... Solarix... The only problem with the distro is that it did not boot :(

Answer 17

the short version

#/bin/bash
$0&
$0

Answer 18

I think the most stupid thing I ever did was to remove the default route on out external facing firewall cluster - whilst vpn'ed to my desktop over a hundred miles away.

Fortunately it was in a period designated as planned downtime (just in case), but that did not save me the 200 mile round trip to go and reconfigure the firewall onsite. It also did not help that this took out our internet exposed production systems for the duration of my travel and subsequent fix.

We all know the definition of a nano-second. An ohno-second is even smaller, and is the time between hitting 'enter' and realising your mistake.

Answer 19

Story told to me:

Another branch called because their local PBX had some issues. After some investigation, we learned that they updated their server, but not their Asterisk configuration. So, the admin decided to instruct the branch guy to redo the configuration.

Admin: "Ok, now, type rm -rf /etc/asterisk"

Guy: "Ok."

Admin: "Now, type cp /var/..."

Guy: "Wait, it is still running..."

Admin: ???... !!!

Answer 20

rm -rf / some/path

instead of

rm -rf /some/path

Luckily it didn't happened to me ;-)

Answer 21

XCOPY is a powerful beast - merciless in it's execution and retarded by the fact that its command line args go in reverse from Window's COPY and UNIX's cp.

A couple days ago I accidentally wrote:

xcopy src \path\to\a\new\nonexistent\directory

XCOPY was kind enough to overwrite my src directory with... nothing! And it didn't bother to put the old files in the Recycle bin either.

Oh, and it turns out that XCOPY actually overwrites the same sectors on the disk instead of allocating new ones. I've tried 3 disk recovery programs, and the best one could only recover 3 of the 10 files lost. Of course those 3 files were only vshost.exe and its pals. Swell!

Answer 22

had trouble with network (on a remote machine) and just wanted to restart the interface

ifconfig eth0 down && ifconfig eth0 upp

Nowadays, I make sure someone is near the machine before trying things like this (iptables is a good candidate as well). And when nobody was there, I once typed

sleep 600; reboot

into another (screen) terminal, so that it would reboot if I could not ctrl+c the command within 10 minutes.

I learned from that mistake as well (ctrl+c the sleep will run the reboot) and now I use

sleep 600 && reboot

which will enable me to ctrl+c it.

Answer 23

source ~/.bash_history

My intention was source .bashrc, but I was too hasty with tab-complete...

Answer 24

Something along the lines of this:

sudo dd if=/dev/zero of=/dev/sda

I meant sda4. I wiped the entire disk, not just the partition :-(

Answer 25

ifconfig eth0 down

Oops, I'm on the external side of eth0. The webserver is on the other side of the world, in a locked room. With no network access to login or reboot. Crap.

Answer 26

A free cookie to anyone who can tell me why I was an idiot for trying to remove all hidden files and directories thusly:

rm -rf .*

Answer 27

While cleaning up my home folder on a production webserver, I forgot that I had symlinked the server's web root to a place in my home folder. Not thinking, I ran an rm -rf on that folder and next thing I know, people are calling that the web site is down!

OOPS!

Answer 28

I was once comparing data in two folders and ran rsync with the -d option (delete files on destination that are not on the source). And then I switched around source and destination when I ran rsync. That deleted all the new files, that I wanted to backup. Now I learned running rsync with -n (dry-run).

rsync -trvd --stats --progress /destination /source

I had no backup.

Answer 29

Once upon a time (probably System III, but it was a long time ago), it was possible to create a file named * by using the right shell quoting. When I found one in my home directory, I had typed rm * and had my finger on the return key when something made me hesitate and think about it...

Creating such a file for other users was a common prank.

If the file is sitting there in a directory, that is a tough one to mitigate. The reflex to just type its name exactly as ls just displayed it is pretty strong.

The other (less harmful) prank was to name files with trailing white space (or only white space) which were much harder to remove...

Answer 30

Due to some bad experience with general JBoss flakiness after a restart, I like to clear JBoss' working files before a restart. I would normally do:

# cd /var/cache/jboss
# rm -rf tmp/* work/*

In order to protect myself from typing any of the many possible disastrous mistakes, like:

• /tmp/*
• tmp /*
• you get the idea

I make the last command:

# sudo -u jboss rm -rf tmp/* work/*

Since the JBoss user would find it difficult to remove any critical files that don't belong to it.

I never actually made that mistake, but I'm safe in the case that I do.