blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (08/03/90)
Didn't you have a X window socket in your /tmp? That is why we could remove /tmp. I also figured that is one of the reasons why the hotline said we couldn't (shouldn't) remove /tmp and replace it with a link to /usr/tmp. Can any one give me any GOOD reasons why we shouldn't remove /tmp and replace it with a link? -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
ciemo@bananaPC.wpd.sgi.com (Dave Ciemiewicz) (08/04/90)
In article <9008031155.AA02414@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > > Didn't you have a X window socket in your /tmp? That is why we > could remove /tmp. I also figured that is one of the reasons why > the hotline said we couldn't (shouldn't) remove /tmp and replace it > with a link to /usr/tmp. Can any one give me any GOOD reasons why > we shouldn't remove /tmp and replace it with a link? > -- > > Brent L. Bates > NASA-Langley Research Center > M.S. 361 > Hampton, Virginia 23665-5225 > (804) 864-2854 > E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov Two reasons I can think of: 1) files in /tmp are automagically removed when cranking up the ol' IRIS. Linking /tmp to /usr/tmp will remove files in /usr/tmp during a reboot. This may annoy some folks though it is something they may be able to get used to. Some people consider files in /usr/tmp to be fair game in this situation. 2) If you boot your system in single user mode, /usr may not be mounted. This means running programs like ex to do configuration file edition in this won't work unless A) you mount /usr or B) you rm /tmp and mkdir /tmp to create yourself a new directory. As long as you are the only individual administering the system, these nusiances may only be minor. They may not be GOOD reasons but they might be FAIR. --- Ciemo
ted@vball.sgi.com (Ted Wilcox) (08/04/90)
In <11369@odin.corp.sgi.com> ciemo@bananaPC.wpd.sgi.com (Dave Ciemiewicz) writes: >In article <9008031155.AA02414@aero4.larc.nasa.gov>, >blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: >> >> Didn't you have a X window socket in your /tmp? That is why we >> could remove /tmp. I also figured that is one of the reasons why >> the hotline said we couldn't (shouldn't) remove /tmp and replace it >> with a link to /usr/tmp. Can any one give me any GOOD reasons why >> we shouldn't remove /tmp and replace it with a link? >Two reasons I can think of: >1) files in /tmp are automagically removed when cranking up the ol' IRIS. >Linking /tmp to /usr/tmp will remove files in /usr/tmp during a reboot. This > ... Is /tmp cleared before or after /usr is mounted? I genuinely don't know the answer, but it would make this a moot point. >2) If you boot your system in single user mode, /usr may not be mounted. >This means running programs like ex to do configuration file edition in this >won't work unless A) you mount /usr or B) you rm /tmp and mkdir /tmp to >create yourself a new directory. As long as you are the only individual >administering the system, these nusiances may only be minor. This one is easy to get around. You simply mkdir /usr/tmp when /usr is not mounted. Then the directory exists, but is on the root filesystem in single user mode. It simple becomes invisible when /usr is mounted. (You do need to be careful not to leave junk in here, though, since it will fill up the root partition with no way to remove it once /usr is mounted. > --- Ciemo ___ Ted. /x \/| I'd kill Flipper ted@sgi.com > \\ | for a tuna sandwich. \___/\| -Flipper (The band) (Thanks Archer.)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/04/90)
In passing, /etc/init.d/RMTMPFILES might be interesting to those who want to make /tmp into a link. That is the script that tries to clean /tmp, /usr/tmp, and so on when the system is started. Vernon Schryver vjs@sgi.com
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (08/06/90)
You gave two reasons for not linking /tmp to /usr/tmp. The first I don't think is valid anymore. I believe /tmp is no longer automatically removed at each reboot. I don't remember which release it was that SGI stopped removing /tmp. The second reason is the first "real" reason I have heard yet. If you don't mound /usr, and therefor /usr/tmp a.k.a. /tmp, you won't be able to use vi or ex. This, to me, however doesn't sound that bad. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (08/06/90)
I looked at /etc/inid.d/RMTMPFILES and it checks to see if /tmp
is linked to something else if it is then the directory is not removed.
I looked at /etc/init.d/RMTMPFILES and it checks to see if /tmp
is linked to something else, if it is then the directory is not removed.
It is also not removed if it or any of its subdirectories are mounting
points.
The file also mentions /usr/tmp_rex, what is this for?
Also I can't find any scripts that execute RMTMPFILES, so it
doesn't seem to be executed.
--
Brent L. Bates
NASA-Langley Research Center
M.S. 361
Hampton, Virginia 23665-5225
(804) 864-2854
E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.govjwag@moose.asd.sgi.com (Chris Wagner) (08/07/90)
In article <66088@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > > In passing, /etc/init.d/RMTMPFILES might be interesting to those who want to > make /tmp into a link. That is the script that tries to clean /tmp, > /usr/tmp, and so on when the system is started. > > > Vernon Schryver > vjs@sgi.com VJS is correct - please everyone - if you do NOT know the answer - do NOT post random info!!!!! In 3.3 we actually tried to allow this since for a while now customers have asked for this ability. The pertinent lines from /etc/init.d/RMTMPFILES: # if /tmp or any of its subdirectories is a mount point do not remove it. # if /tmp symbolic links to other directory do not remove it. M=`mount | grep ' on /tmp' | wc -l` if [ $M -eq 0 ]; then if [ ! -l /tmp ]; then rm -rf /tmp mkdir /tmp fi fi As for running in single user mode - things like ex/ve are in /usr/bin - so noone will be running those without /usr mounted! As for the X socket - I believe in order to start this whole scenario - one need to log out, and log back in as root NOGRAPHICS - this way news and X will not be started up - here is your chance to link /tmp and /etc/gl Notice that the 3.3 installation tools HANDLE symbolic links just fine - I personally have my /usr/demos and /usr/adm/crash symlinked onto another disk Chris Wagner
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/07/90)
In article <9008061227.AA11480@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > > Also I can't find any scripts that execute RMTMPFILES, so it > doesn't seem to be executed. The nodes in /etc/rc[23].d are usually symbolic links to /etc/init.d. The are run by /etc/rc[23], which are run by init when "changing state," as directed by /etc/inittab. The SVR3 idea of the /etc/init.d files is to permit the old rc, rc.local, and (on 3000's) other rc.* files to be divided by function, so that you can install or remove things without hacking rc files, and can start and stop portions of the system. This stuff is partially documented in init(1M). I recall reading the AT&T words describing the general /etc/init.d scheme in some "Administrator's Guide." Vernon Schryver vjs@sgi.com
root@sgzh.uucp (Bruno Pape) (08/07/90)
In article <11455@odin.corp.sgi.com> jwag@sgi.com (Chris Wagner) writes: > >VJS is correct - please everyone - if you do NOT know the answer - do NOT post >random info!!!!! > lighten up. If one can't handle random info one shouldn't use a computer. bruno