problem after rm -rf *

[prasadb]

hello admins,

just out of curiosity,on one of my test server i fired #rm -rf * to see which files will be deleted, now i am unable to telnet and run any command...

but to my surprise its running only pwd and cd command but not /usr/bin/pwd and /sbin/ls..

can anybody throw some light on reason for this

and is there any way to recover the system..

thankx in advance..

[Robert-Jan Goossens_1]

Hi,

These commands are in memory, you can not use the /usr/bin/pwd etc because they are not there anymore.

You will have to recover from a make_tape(net)_recovery or reinstall from cd.

Best regards,
Robert-Jan

[Yogeeraj_1]

hi,

You will have to restore from your ignite backup. Some commands are inbuilt in the shell, that is why you are able to run them.

good luck!
kind regards
yogeeraj

[Dennis Handly]

>just out of curiosity, on one of my test server i fired #rm -rf * to see which files will be deleted

You did this in /?
Isn't it obvious what will happen?

[James R. Ferguson]

Hi:

You will now need to rebuild (cold-install) your server.

The fact that 'cd' and 'pwd' continue to run may be due to the presence of these commands as shell built-ins in addtion to being standalone executables.

As for recovering your server, I trust that you have a good Ignite backup image. You will certainly need to rebuild from scratch, otherwise!

Regards!

...JRF...

[Torsten.]

"i fired
#rm -rf *
to see which files will be deleted"

Now you know it ... if you would ask instead, it would be not that painful ...

[Court Campbell]

At least it didn't say:

"i was fired after #rm -rf *"

[Torsten.]

Sometimes it helps to read the man page to understand the commands, even it is for a test system:

http://docs.hp.com/en/B2355-60103/rm.1.html

Your command forced to delete everything below your current directory.



But now you have a very solid status and plenty of space on the disks ...

;-)

[Steven Schweda]

Yet another reason to use the scheme (common
on Linux systems) of giving "root" a home
directory other than "/", like "/root". It
doesn't actually educate (or raise the IQ of)
the fellow who has the "root" password, but
it can help to limit the damage in a case
like this. (Some of the time, at least.)

> [...] to see which files will be deleted
> [...]

Which files did you think that it _wouldn't_
delete?

> and is there any way to recover the
> system..

And the best time to think about this is
when?

[Torsten.]

>> And the best time to think about this is
when?

I guess the answer is: NOW.

__LOL__


You just found 1 out of many ways to destroy the system, but there are sooo many other ways ... if you want to test some others, let us know ...

Keep smiling.

[Bill Hassell · Accepted solution]

Congratulations! You are now a member of the "rm -rf *" Club. There are many members, most of them are sadder but wiser system administrators (or unemployed). There are a couple of additional Clubs for you to join (if you haven't already become a member):

The "chmod -R 777 *" club
The "chown -R root:bin *" Club

As mentioned, the "/" directory is the *WORST* possible location for root's HOME yet unfortunately, this is the default for virtually all flavors of UNIX. Never cd to / unless you are shutting down. Never execute any command that can recursively act on files and directories until you have previewed the command (ie, rm -i *) and now that you know the consequences, put these aliases in /etc/profile:

alias rm="/usr/bin/rm -i"
alias cp="/usr/bin/cp -i"
alias mv="/usr/bin/mv -i"

This will help immensely by prompting you with something like this:

rm -i -rf *
/stand/vmunix: ? [y/n]

AS you might expect, it would be a bad thing to remove /stand/vmunix...etc.

Another really useful command is: type

This is actually an alias to "whence -v" and is the only useful way to determine what will be run when you type a command. In your case:

# type pwd cd ls
pwd is a shell builtin.
cd is a shell builtin.
ls is /usr/bin/ls

The commands: which and whereis are useless in telling you what will happen in the shell. For instance, in my shell, I get this:

pwd is an alias for /usr/bin/pwd
cd is a shell builtin.
ls is an alias for /usr/bin/ls -aF

In other words, I am *NOT* running the 'normal' commands because I have aliased pwd and ls. The reason for pwd is to show the 'real' directory when using cd in the shell to follow a transition link. For example:

$ cd /usr/spool/lp/interface
$ type pwd
pwd is a shell builtin.
$ pwd
/usr/spool/lp/interface
$ /usr/bin/pwd
/etc/lp/interface

The shell can be a bit misleading at times...

[prasadb]

thank you all..

Bill i was just wondering to know what is

The "chmod -R 777 *" club
The "chown -R root:bin *" Club are all about ?

can you throw some light on these ?

[Yogeeraj_1]

hi,

>The "chmod -R 777 *" club
>The "chown -R root:bin *" Club are all about ?


these were just anecdots that Bill has used just to say that there have been people before you who have had the same incident before. So, you are not the privileged member of this club... :)


Nothing to worry about. It was just a joke!

kind regards
yogeeraj

[Venkatesh BL]

>The "chmod -R 777 *" club
>The "chown -R root:bin *" Club are all about ?

Please don't try this!, else, you may have to post one more query :)

[prasadb]

thanx yogiraj, and all who gave me their precious time to answer my doubts and question...

[Dennis Handly]

>Bill: The reason for pwd is to show the 'real' directory when using cd in the shell to follow a transition link.

No need to do this. Just use a real shell. A real shell has "pwd -P" to give you the physical path. Of course the default is "pwd -L".

>prasadshete: Bill i was just wondering to know what is
>The "chmod -R 777 *" club
>The "chown -R root:bin *" Club

Well, you don't want to join these clubs.
But since you're paid up member of the rm -rf club, you can get a very cut rate membership, provided you do it BEFORE you restore you broken system. :-)

>Yogeeraj: Nothing to worry about. It was just a joke!

It isn't a joke if you join the club.
Basically don't do those commands.

[Heironimus]

The problem with aliasing things to use "-i" is that it leads people to habitually use "-f". In particular, "rm -rf" becomes the One True Way to delete anything. I always cringe a little inside as I watch otherwise-good admins use "rm -rf something*" when they specifically want to remove normal files.

[James R. Ferguson]

Hi (again):

> Heironimus: The problem with aliasing things to use "-i" is that it leads people to habitually use "-f".

As one who *prefers* to alias 'rm' to 'rm -i', I understand your comment. _However_, I look at the requirement to answer the prompt as a nice "are your sure?" that makes me think a fraction of a second before I commit.

If I have several files to remove, and I _do_ want to avoid the interactive prompts, I don't have any problem typing a few more characters to yield:

# /usr/bin/rm file1 file2 file3 ...

...which circumvents the interaction.

Regards!

...JRF...

[Heironimus]

When I say "habitually" I mean they typed "rm -rf" every time they removed anything as any user, even when using accounts or machines that didn't have the alias set, and always without thinking. In doing so, they bypassed the friendly "are you sure" confirmations and "can not remove directory" errors.

[Dennis Handly]

>ME: Well, you don't want to join these clubs.

I just thought of one way to do these normally dangerous experiments. Set up a chroot(1m).
After you have hosed yourself a few times, just "exit" back to the real world.

[Stephen Keane]

The best one I've seen to date, run as root in a script designed to "trim" a log file directory.

...
export LOG_DIR="blah"
...

cd $LGO_DIR
rm -fr *.*

[Patrick Wallek]

That is precisely why one should always put a 'set -u' in scripts. That way the script would error out before doing the 'rm'.