Xref: utzoo comp.misc:9943 comp.unix.questions:25025
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!decuac!shlump.nac.dec.com!tkou02.enet.dec.com!diamond
From: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Newsgroups: comp.misc,comp.unix.questions
Subject: Re: Your favourite rm in /tmp (was: Your favourite UNIX-pipe (...))
Message-ID: <1934@tkou02.enet.dec.com>
Date: 26 Aug 90 23:54:57 GMT
References: <730@coma.UUCP> <2987@awdprime.UUCP> <2400@dino.cs.iastate.edu> <4002@rtifs1.UUCP> <58702@bbn.BBN.COM> <7249@star.cs.vu.nl> <13633@ulysses.att.com>
Reply-To: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Followup-To: comp.misc
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 20

In article <13633@ulysses.att.com> andys@ulysses.att.com (Andy Sherman) writes:

>Umm, be careful.  We had a mysterious problem here with X11, where
>after about 3 days new clients could not be started up to
>DISPLAY=unix:0.0.  I finally figured out that our /tmp cleanup script,
>which gets rid of trash which has not been accessed for 3 days, was
>removing the UNIX(R) domain socket from /tmp/x11-unix.  :-(.

You mean you put a non-temporary file in /tmp?  Maybe you were asking
for trouble.  If I want a file to last even a day, I put it somewhere
other than /tmp or /usr/tmp.

Incidentally, speaking of cleanup problems, be careful if it's possible
to link another machine's disk into /tmp.  Yeah, like if someone's
testing nfs or a competitor of nfs, so "find" thinks it sees ordinary
disks (not type nfs) and goes ahead and wipes out the served disk.
(No, it didn't happen here.)
-- 
Norman Diamond, Nihon DEC       diamond@tkou02.enet.dec.com
Steering like a sports car:  I use opinions; the company uses the rack.