I’m working on a some materials for a class wherein I’ll be teaching some young, wide-eyed Windows nerds about Linux and we’re including a section we’re calling “foot guns”. Basically it’s ways you might shoot yourself in the foot while meddling with your newfound Linux powers.
I’ve got the usual forgetting the .
in lines like this:
$ rm -rf ./bin
As well as a bunch of other fun stories like that one time I mounted my Linux home folder into my Windows machine, forgot I did that, then deleted a parent folder.
You know, the war stories.
Tell me yours. I wanna share your mistakes so that they can learn from them.
Fun (?) side note: somehow, my entire ${HOME}/projects
folder has been deleted like… just now, and I have no idea how it happened. I may have a terrible new story to add if I figure it out.
Running the right command on the wrong SSH session/machine.
I set a different background color on all my machines because of exactly this while using VNC/RDP
this. after i set different zsh themes on my servers + my main machine i now know exactly what machine i’m running commands to
An older friend of mine told me years back about an incident that happened on a university VAX running Unix. In those days, everyone was using vt100 terminals, and the disk drives weren’t all that quick. He was working on his own terminal when without warning, he got this error when trying to run a common command (e.g.
ls
)$ ls -l sh: ls: command not found
So he went on over to the system admin’s office, where he found the sysadmin and his assistant, staring at their terminal in frozen horror. Their screen had something like:
# rm -rf / tmp/*.log ^C^C^C^C^C^C^C^C^C^C # ls -l sh: ls: command not found # stat /bin/ls sh: stat: command not found
A few seconds after hitting return, and the
rm
command not finishing immediately, he realised about the errant space, and then madly hammered Ctrl-C to try to stop it. It turns out that the disk was slow enough that not everything was lost, and by careful use of the commands that hadn’t been deleted, managed to copy the executables off another server without having to reinstall the OS.Oh no, that’s horrifying.
Using sudo when it isn’t necessary, and the real cannon: sudo su… Adding sudo to your command lines indiscriminately causes files you create to be owned by root even though they are in your home directory, and then you end up using sudo to make changes to the files… and then the filesystem permissions cannot prevent you from successfully running an accidental “sudo rm -rf /” command.
Seriously… sudo is not a “habit” to develop in order to avoid dealing with filesystem permissions problems.
I was working on my final project in a class in undergrad on the campus VAX. VMS had a versioned filesystem, which is to say that every time you saved a file (like your source code in LSE), it would create a new file (e.g.,
FINAL.COB;23
). I was getting confused by all of the versions of my project so I decided to clean some of the older ones out:DELETE FINAL.COB;1*
DELETE FINAL.COB;2*
I had to run to the data center the VAX was in halfway across campus to beg the sysadmins to restore
$STUDENTS:[DRWHO.CS1337]FINAL.COB;*
from the hourly tape backup (at least there was that) and re-debug the last two functions so I could hand it in before midnight. Lesson learned: Don’t worry about cleaning up your workspace until after you’re done.These days we snapshot
I wanted to try inserting and removing kernel modules, so I looked around and thought “well, I don’t have a USB stick in right now so I can safely try removing the usb kernel module.” So I did that, and after pressing enter I realized my keyboard is connected with USB.
The dumbest must have been when I went through the list of installed packages on Debian and removed everything named “python-…” since I don’t program in python.
- Accidentally did a partial upgrade of Arch Linux in which I upgraded libssl but not systemd (which depended on it) (which refused to start becuase one of its dependencies had been upgraded to an incompatible version) (which caused the kernel to panic immediately on bootup because the init process died) (writing init=bash on the kernel command line gave me a shell but not network access) (i had to boot off a liveusb, chroot into my /, and run pacman -Syu from there in order to fix it)
- Use Ubuntu, at all, for anything, ever
deleted by creator
Mine falls along with the people who were distracted. Was doing two deployments for work on night and on one I need to clear a cache. As I was typing the cd command, I happened to glance at the instructions for the other deployment and for some reason my mind switched to the deployment folder. I then typed out rm -rf *, and as I hit return realized I wasn’t in the cache subdir. Blew away our prod environment and it took hours to get it all restored. The restore kept asking the guy to go pull tape #xxx. It was nerve wracking because depending on the tape, there was a chance it was moved offsite. Got it all restored and turned it back on, and then had to start back from the beginning since the backup was from the night before. The other people doing deployments weren’t too happy, but I owned up immediately and we ended up changing the procedure. First, the cache clearing was done via a script after that, and I won my argument about not having to do two deployments simultaneously!
Not me, and not Linux, but a school mate found the following bash snippet online
:(){ :|:& };:
.Naturally, he tried it on the SunOS servers we had access to for schoolwork. He got his account suspended for the rest of the year.
I think most Linux distros are configured to kill fork bombs nowadays.
deleted by creator
Once I omitted a semicolon after an “rm -rf”and the next command. The script was supposed to reduce downtime vs typing the commands manually, but instead it deleted the production site and the “.bak” backup of the site instantly.
I totally pulled a LTT and removed my kernel. >_< There was a “real time” kernel listed in apt, and I installed it because I was curious if it would reduce lock latency for a project I was working on. (I wasn’t trying to solve a problem, just curious) It didn’t and I figured it was probably a bad idea to leave it installed. So I did an apt remove, and the rest went something like this.
Apt: Are you sure you want to remove the your kernel? Y/N
Me: Oh jeez… I don’t want to do that.
Motor Memory: Y <return>
Apt: Are you really really sure? Your computer will not boot if you do this. Y/N
Me: Oh, crap! That’s not what I meant to do. Definitely not!
Motor Memory: Y <return>
Me: No! Why would my brain betray me!?
Fortunately this was on a PopOS machine, so I booted into the recovery partition. Even if fixing it only took a minute, I still felt very very dumb. >_<
Man, that’s a really dumb story that I find really relatable despite not having had any experiences like that. It feels like it’d be very in character for me though. Thanks for sharing, it helps me feel less silly in the various times where I’ve messed up (of which I am struggling to recall specific examples, but whatever brain part is responsible for embarrassment can remember, apparently)
I have made countless mistakes since the 90s, mostly involving rm. The most recent one was yesterday when I was trying to rm files in a directory with lots of other unrelated files.
I don’t remember the exact failure, but I was shooting for something like
rm *lng
and typo’edrm *;ng
(those chars are next to each other on the kb). This happily rm’ed * (d’oh!) then errored on the nonexistance ng. :-(Force uninstalled glibc on my Gentoo, which basically broke every shell and binary on the system. Was able to repair in place because I
- Had already compiled busybox statically
- Still had a copy of the stage 3 tarball on / which I could use to ‘restore’ glibc libraries