Jump to content

I was close to having the site transferred...


SDS

Recommended Posts

I don't think he meant you Jay Rubeo.  I think he meant that other Jay, that Jay Rosen guy that could never get anything right! <_<

8725[/snapback]

 

Yeah, I'm glad we banned him. I think he's launching DOS attacks on the board in retribution for being banned though....

Link to comment
Share on other sites

Yeah, I'm glad we banned him.  I think he's launching DOS attacks on the board in retribution for being banned though....

8797[/snapback]

 

I've met both Jay Rosen and Jay Rubeo. Rubeo is a much nicer guy than Rosen was. They do look shockingly similar though.

Link to comment
Share on other sites

yeah i know, but it happened.  was an older RH distro, 5.? or 6.? i think

8763[/snapback]

 

I hate when we start talking about stuff like this because I can't get any work done until we figure it out. ;-)

 

The entire "rm" command isn't necessarily guaranteed to be 100% in memory. But at the same time, the data that an inode references shouldn't be released until all file handles referencing it are closed.

 

Earlier Linux kernels handle that weird-like or something?

 

-Jeff

Link to comment
Share on other sites

I hate when we start talking about stuff like this because I can't get any work done until we figure it out.  ;-)

 

The entire "rm" command isn't necessarily guaranteed to be 100% in memory. But at the same time, the data that an inode references shouldn't be released until all file handles referencing it are closed.

 

Earlier Linux kernels handle that weird-like or something? 

 

-Jeff

8852[/snapback]

 

Makes things more difficult when only 3-4 people on the board know what we're talking about :o

 

I don't have a lot of Linux experience (ran Slakware 10 years ago so that I could do OpenGL programming on a non-Irix box, but that's about it). That's the only thing that makes sense though -- that Linux broke it. Either that, or maybe the command was more like:

 

for i in `ls /`

do

rm -rf $i

done

 

I can see how that would stop after the rm file was removed...

 

Strange stuff -- someone setup a test box and see if we can reproduce the problem! <_<

 

CW

Link to comment
Share on other sites

Could this be the response when the process' PID "directory" is wiped? I know in Solaris at least, all PID info is "saved" in a directory....It's difficult to pinpoint because everything in a *nix system is represented by a file these days....

Link to comment
Share on other sites

Could this be the response when the process' PID "directory" is wiped?  I know in Solaris at least, all PID info is "saved" in a directory....It's difficult to pinpoint because everything in a *nix system is represented by a file these days....

8918[/snapback]

 

Ahh, the /proc filesystem. Possibly... Could probably test it by doing an rm -rf /proc / -- I think it would execute the /proc first and then everything under /.

 

Anyone have a test box that they can blow up? I don't <_<

 

CW

Link to comment
Share on other sites

I do.. hold on.... (doobie doobie doo..)

8969[/snapback]

 

No go, I should have figured this prior to trying it out... /proc is read only and all of that data under the "PID directory" comes from various areas of the kernel. Can't wipe..

 

Lets try the rm -fr /

 

...

Link to comment
Share on other sites

[root@localhost proc]# rm -fr /

rm: cannot remove directory '//dev/pts': device or resource busy

...

...

...

Few more devices in use and cannot be whacked.

rm: '//sys/block/hdc/device' changed dev/ino: Operation not permitted

[root@localhost proc]# rm -fr /

-bash: /bin/rm: No such file or directory

 

Machine killed. Whacked 'rm' and kept going =)

Link to comment
Share on other sites

[root@localhost proc]# rm -fr /

rm: cannot remove directory '//dev/pts': device or resource busy

...

...

...

Few more devices in use and cannot be whacked.

rm: '//sys/block/hdc/device' changed dev/ino: Operation not permitted

[root@localhost proc]# rm -fr /

-bash: /bin/rm: No such file or directory

 

Machine killed. Whacked 'rm' and kept going =)

8979[/snapback]

 

Fair enough. Must've been something funky with an old Linux kernel. Or /dev/null is getting old and forgetful about what really happened <_<

 

CW

Link to comment
Share on other sites

Fair enough.  Must've been something funky with an old Linux kernel.  Or /dev/null is getting old and forgetful about what really happened <_<

 

CW

8990[/snapback]

 

Yeah, must be. The fact that bash kept working after the remove finished illustrates the point nicely, though.

Link to comment
Share on other sites

×
×
  • Create New...