Hacker News Reader

Comment by gjulianm | Hacker News Reader

I've always preferred this tougher command to screw VMs I was going to delete.

    dd if=/dev/random of=/dev/sda

Depending on how long does it run, you end up with a more or less screwed computer. It's funny to see how does the machine fall over when you invoke a simple 'cd' command after this.

View on HN

It's not so funny when you do this accidentally, on a 2 TB disk full of user data, on a live production server, at 2AM on a Friday night...

(The server was part of a MogileFS cluster so there were multiple copies of the data online. There was no data loss, not even any downtime. Still, it was scary as hell, and I spent all Saturday in the data center restoring the box.)

how did you end up doing this accidentally?

I've seen stranger: a redirect gone the wrong way

    $ foo < bar  # runs command `foo`, reading from `bar` on stdin
    $ foo > bar  # runs command `foo`, writing stdout to `bar`

Writing `>` instead of `<` has resulted in many a blowup at 3 AM

I did this with a DELETE SQL WHERE clause, trying to isolate a set of records, instead selecting all records, in an effort to test a production installation, at 3am (YES) and had to buy 3 db admins lunch the following day because they came in to restore multiple customer tables. The DELETE's were triggered across numerous tables and platforms (AS400 and SQL Server). The walk of shame to tell my director was not my most shining moment. I'd like to go back in time and slap myself just moments before. Running commands on live production data. Silly programmer.

At least with MySQL's tools, thanks to ssh's happiness to work as a pipe, it's very easy to clone a database locally for fucking about when you're trying to do something like this:

  ssh remotehost.example.com mysqldump -udbuser proddatabase | mysql -uroot testdatabase

(n.b. the mysqldump options that may lock your production tables during the dump.)

My friend did this...

  rm * -i

The system response was "-i not found" or something like that.

I once discovered that apparently

  rm bob*

has completely different behavior from

  rm bob *

The above line of code successfully fixed a bug I'd been trying to find for weeks in source code in the same directory. When I rewrote it from scratch, the bug was gone.

This is certainly different. " bob* " refers to all files that start with "bob". " bob * " refers to a file named bob as well as all files.

Thank you, Donny.

rm -i is your friend

I find rm -i to be unusable because it is so annoying when you are deleting more than a couple files. It would be nice if rm -I (notice the capital) would first determine all of the files to remove, print them out and then ask if you want to delete all of those files. Instead it just says "rm: remove all arguments?" which is clearly much less annoying than having to type y for every file, but it is also mostly useless.

Zsh almost does this when using rm * :

  rm /tmp/*
  zsh: sure you want to delete all the files in /tmp [yn]?

protip: always put -i first.

I avert the problem by having rm run interactively by default:

    alias rm='rm -i'
    alias cp='cp -i'
    alias mv='mv -i'

http://aniggler.tumblr.com/post/44530262158/the-first-thing-...

Until one day, lulled into a false sense of security, you find yourself on a system without these aliases…

I usually don't alias the command itself; that's bad form. It limits what you can do and screws you when you are using an environment without your alias when you forget it. Live and learn.

Exactly -- I was benchmarking a disk that was having a performance problem. and I did something like "dd if=/dev/zero of=/dev/sda" instead of "of=/testfile".

That doesn't sound so bad. /dev/random is slow, you have plenty of time to catch it. It probably won't even reach the first partition. urandom on the other hand...

Depends on your system. In BSD /dev/random is /dev/urandom.

/dev/zero is plenty fast... :-/

Aahhh. In the old days, we used this command just to mess with your workmates.

  while :
  do
     clear > /dev/tty
     sleep 5
  done

We wrote our own shell when I was at university (which was completely offensive, not at all obedient and generally no help whatsoever) and chsh'ed them if they left a terminal open :)

(for ref, we had to do very naughty things to SunOS 4 to add it to /etc/shells)

/usr/games/worms is the best shell ever.

Never thought of that - great suggestion :)

Back when `/dev/mem` was a thing in default kernels (now you need a special config, or a module), I enjoyed `cat /dev/urandom > /dev/mem`. That would usually bork things pretty quickly, so then I would set random offsets with `dd`. Fun times.

See also kmem Russian Roulette: https://twitter.com/shadowcat_mst/status/754107237269504

Or try this -- http://git.zx2c4.com/memory-hemlock/tree/slow-death.c

It picks a random device on your system -- ram, video, bios, etc -- and writes a random number of random bytes into it and then sleeps for a random amount of time.

Last one standing lives.

What's /dev/sda?

On Linux, the hard disk. This command, dd, copies data in bulk from /dev/random (a special device on *nix that outputs random bytes) to /dev/sda (your hard disk). That means it starts to overwrite your disk with trash, rendering the system unusable.

I know what `dd` is. I just don't use Linux, so I'm not particularly familiar with the Linux-specific /dev entries. Thanks though.

Most probably the storage device which is your HD.

Probably your main drive.

The device file applications can use to access the first hard drive on most Linux systems. It provides raw access without filesystems or partitions.

/dev/sda1 is the first partition on that drive, /dev/sda2 the second, and so on. /dev/sdb is the next hard drive, /dev/sdc the next after that; beyond /dev/sdz, the naming scheme is apparently dependent on the hardware driver in use: Going from /dev/sdz to /dev/sdaa is what happens in the default SATA and SCSI drives, up to /dev/sdzzz, at which point you apparently run into problems. [1]

http://rwmj.wordpress.com/2011/01/09/how-are-linux-drives-na...

[1] http://kerneltrap.org/mailarchive/linux-scsi/2010/9/20/68866...

Reply on news.ycombinator.com