Tag Info

Hot answers tagged

146

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. ...


25

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 ...


24

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.


23

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 ...


23

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?


19

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 ...


16

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 ...


15

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 ...


14

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.


14

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


13

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. ...


11

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 ...


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

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 ...


10

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


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

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 ...


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 ...


8

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 ...


8

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

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.


7

Here's a bash function that can be sourced from .bashrc to add a warning when you use rm with more than 2 arguments: unalias rm 2>/dev/null real_rm=/bin/rm rm_opts="" function confirm { echo -n "Do you want to continue (Y/N)? " read v v=$(echo $v|tr '[a-z]' '[A-Z]') if [[ "$v" == "Y" ]]; then return 0 elif [[ "$v" == "N" ]]; then ...


7

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.


7

You will most likely find that you have rm aliased to rm -i. If you had answered y to the question you would then have been asked to authorise the deletion of each file in each directory. $ alias rm alias rm='rm -i' $ rm -r tmp1 rm: examine files in directory tmp1 (yes/no) y rm: remove tmp1/1 (yes/no) y rm: remove tmp1/2 (yes/no) y rm: remove tmp1: ...


7

Try removing the escaped double quotes. I believe rm thinks those are part of the filename. find ./ -inum 167794 -exec rm {} \;


7

All that happens is that you reduce the file's link count by one. If the link count reaches zero, the space on the disk is marked as available for re-use, but it is not overwritten immediately. This can bite you two ways: 1) If the file's link count wasn't 1 to begin with, the delete operation isn't actually a delete, it's just an unlink. So the file's ...


7

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. ...


7

rm -- ----------9976723563nneh4_-----192.9.200.4 You need -- in order to tell rm (and more or less all other GNU software) that all following parameters are file names even when beginning with "-". Otherwise (and in your case) the file name is confused with options. Another possibility is rm ./----------9976723563nneh4_-----192.9.200.4 Edit 1 Calling ...


7

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 ...


6

The -r switch acts exactly how its name implies: recursively. It executes the same action on each and every file and directory inside the current directory, before removing it. So, yes, being quite slow for large (as in "with lots of different things inside") directories is absolutely normal. One of the biggest (and most feared) signs you mistyped a rm -rf ...



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