Hot answers tagged

173

One of the tricks I follow is to put # in the beginning while using the rm command. root@localhost:~# #rm -rf / This prevents accidental execution of rm on the wrong file/directory. Once verified, remove # from the beginning. This trick works, because in Bash a word beginning with # causes that word and all remaining characters on that line to be ignored. ...


45

One rare possibility could be you triggered some of the infamous UEFI bugs, that already killed some series of Samsung and Lenovo notebooks. It works like this: UEFI specs propose a non volatile memory (nvram or eeprom) that can be accessed by the OS to store settings or debugging information. Linux actually uses this feature in case of a kernel panic: If ...


34

Whilst a major cause of this problem is ext3 performance with millions of files, the actual root cause of this problem is different. When a directory needs to be listed readdir() is called on the directory which yields a list of files. readdir is a posix call, but the real linux system call being used here is called 'getdents'. Getdents list directory ...


33

Your problem: I just ran rm -rf /* accidentally, but I meant rm -rf ./* (notice the star after the slash). The solution: Don't do that! As a matter of practice, don't use ./ at the beginning of a path. The slashes add no value to the command and will only cause confusion. ./* means the same thing as *, so the above command is better written as: rm ...


27

No, it is not possible to destroy the BIOS (legacy or UEFI) in this manner with that command. Even if you somewhat managed to destroy the UEFI partition, core BIOS files will not be affected, as they reside in non-volatile memory (flash-based, mostly) socketed on your motherboard. UEFI partition hosts additional software components (eg: debugger, driver, ...


27

Would it be possible to backup all of the other files from this file system to a temporary storage location, reformat the partition, and then restore the files?


26

If you've got GNU find then you probably want find <directory name> -name '*.pyc' -delete If you need something portable then you're better off with find <directory name> -name '*.pyc' -exec rm {} \; If speed is a big deal and you've got GNU find and GNU xargs then find <directory name> -name '*.pyc' -print0|xargs -0 -p <some ...


26

Since this is on "Serverfault", I'd like to say this: If you have dozens or more servers, with a largish team of admins/users, someone is going to rm -rf or chown the wrong directory. You should have a plan for getting the affected service back up with the least possible MTTR.


20

The data=writeback mount option deserves to be tried, in order to prevent journaling of the file system. This should be done only during the deletion time, there is a risk however if the server is being shutdown or rebooted during the delete operation. According to this page, Some applications show very significant speed improvement when it is used. For ...


17

Upgrade to ext4 or some other modern filesystem that uses extents. Since ext3 uses the indirect blocks scheme rather than extents, deleting large files inevitably entails lots of work.


17

The best solutions involve changing your habits not to use rm directly. One approach is to run echo rm -rf /stuff/with/wildcards* first. Check that the output from the wildcards looks reasonable, then use the shell's history to execute the previous command without the echo. Another approach is to limit the echo command to cases where it's blindingly ...


15

Yes: Don't work as root and always think twice before acting. Also, have a look at something like https://launchpad.net/safe-rm.


14

You could always do an alias, as you mentioned: what_the_hell_am_i_thinking() { echo "Stop." >&2 echo "Seriously." >&2 echo "You almost blew up your computer." >&2 echo 'WHAT WERE YOU THINKING!?!?!' >&2 echo "Please provide an excuse for yourself below: " read echo "I'm sorry, that's a pathetic excuse. ...


13

The most interesting answer was originally buried in a comment on the question. Here it is as a first class answer to make it more visible: Basically no method from here worked, so we developed our own. Described it in here: http://www.depesz.com/index.php/2010/04/04/how-to-remove-backups/ – depesz Apr 6 '10 at 15:15 That link is an incredibly ...


12

I was having the same issue, I was trying and failing to delete /usr/local/tomcat/data with the error rm: cannot remove/usr/local/tomcat/data': Device or resource busy` until I noticed that df -h said /dev/vda3 20G 172M 20G 1% /usr/local/tomcat/data that is, I had a partition mounted to that point. Mystery solved.


11

There is no per directory file limit in ext3 just the filesystem inode limit (i think there is a limit on the number of subdirectories though). You may still have problems after removing the files. When a directory has millions of files, the directory entry itself becomes very large. The directory entry has to be scanned for every remove operation, and ...


11

There's some really bad advice in this thread, luckily most of it has been voted down. First of all, when you need to be root, become root - sudo and the various alias tricks will make you weak. And worse, they'll make you careless. Learn to do things the right way, stop depending on aliases to protect you. One day you'll get root on a box which doesn't ...


10

This is standard of mine specifically for regexps in the context of rm, but it would have saved you in this case. I always do echo foo*/[0-9]*{bar,baz}* first, to see what the regexp is going to match. Once I have the output, I then go back with command-line editing and change echo to rm -rf. I never, ever use rm -rf on an untested regexp.


10

It may be faster to zero/truncate the file than remove it. I also mention this because that's a really large log file, so there must be a tremendous amount of process activity writing to it. Try : > /path/to/logfile.log if you're not in a position to stop and start the production services.


10

While fun, rm -rf / can only break a havoc inside its own little jail -- and that is the partition(s) it is given. It cannot mess up disk MBR, nor it cannot magically destroy your computer. Something else is wrong in your case.


10

I really hope you have already taken the affected partition offline so to prevent data been written on top of the deleted data. One useful tool that has worked for me in the past is extundelete. Remount the affected partition as read only and then use extundelete to recover the data. I suppose it is pointless to reiterate that prevention is always better ...


10

mkdir /var/run chmod 755 /var/run that will fix most things, anything that still doesn't work will just need to be restarted edit: restarted as in, /etc/init.d/ssh restart which will recreate /var/run/sshd. you may have some issues with the pid files being missing, nothing a manual pkill won't fix.


10

alias rm='rm --preserve-root' IIRC --preserve-root is the default in newer versions of coreutils.


9

Most likely the attacker has set the immutable attribute on the files and directory. This is commonly done by rootkits to make cleanup more difficult. To confirm this, try: lsattr /_bin To remove the immutable attribute, use: chattr -R -i /_bin You'll also want to clear the a and s attributes, since these may affect your ability to remove the files. ...


9

Removing files performs only metadata operations on the filesystem, which aren't influenced by ionice. The simplest way would be, if you don't need the diskspace right now, to perform the rm during off-peak hours. The more complex way that MIGHT work is to spread the deletes out over time. You can try something like the following (note that it assumes your ...


9

ionice -c3 rm yourfile.log is your best shot, then rm will belong to idle I/O class and only uses I/O when any other process does not need it. ext3 is not stellar when deleting huge files and there's not very much you can do about it. Yes, the rm command will slow down your system. The amount of slowness and the duration of the deletion is something one can ...


8

The solution to this problem is to take regular backups. Anytime you produce something you don't want to risk losing, back it up. If you find backing up regularly is too painful, then simplify the process so that it's not painful. For example, if you work on source code, use a tool like git to mirror the code and keep history on another machine. If you work ...


8

The simplest way to prevent accidental rm -rf /* is to avoid all use of the rm command! In fact, I have always been tempted to run rm /bin/rm to get rid of the command completely! No, I'm not being facetious. Instead use the -delete option of the find command, but first before deleting the files I recommend previewing what files you'll be deleting: find | ...


8

For single files, or small sets of files, if wildcard globbing doesn't allow you the precision you feel you need, you can combine ls -i (or stat, if available) and find -inum. For example: ~$ ls -i myweirdfile 183435818 myweirdfile ~$ find . -inum 183435818 -exec rm -i '{}' ';' rm: remove regular file `./myweirdfile'? y ~$ Alternatively, in a single ...


8

The other answers seem to agree that wiping the BIOS is probably not your problem, so here's another thought: My computer, when switched into UEFI mode, skips the BIOS screen completely. No manufacturer's logo, no nothing. It just tries to boot and tells me there's no bootable media (or boots). If I remember the key to enter setup, I can whack it as the ...



Only top voted, non community-wiki answers of a minimum length are eligible