Dan Gross Posted August 27, 2004 Posted August 27, 2004 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....
Just Jack Posted August 27, 2004 Posted August 27, 2004 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.
mcjeff215 Posted August 27, 2004 Posted August 27, 2004 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
Fezmid Posted August 27, 2004 Posted August 27, 2004 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 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
Dan Gross Posted August 27, 2004 Posted August 27, 2004 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....
Fezmid Posted August 27, 2004 Posted August 27, 2004 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
mcjeff215 Posted August 27, 2004 Posted August 27, 2004 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 / ...
mcjeff215 Posted August 27, 2004 Posted August 27, 2004 [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 =)
Fezmid Posted August 27, 2004 Posted August 27, 2004 [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
/dev/null Posted August 27, 2004 Posted August 27, 2004 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] huh, what we were talking about? where's my dern aarp newsletter
mcjeff215 Posted August 27, 2004 Posted August 27, 2004 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.
Recommended Posts