> -----Original Message-----
> From: Linux on 390 Port [mailto:[email protected]] On
> Behalf Of Philip Rowlands
> Sent: Friday, March 11, 2011 8:52 AM
> To: [email protected]
> Subject: Re: cleaning up /tmp
>
> On 11/03/2011 14:23, McKown, John wrote:
> > There's a discussion going on over on the MVS-OE forum (which I
> > started) about the /tmp subdirectory. It's gone away from
> my original
> > towards how to keep it clean. So I thought I'd ask the UNIX wizards
> > over here what the "industry standard" is.
>
> I don't speak for "industry", but here are some Linux standards:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFI
> LESPRESERVEDBETWEE
>
> > One thing mentioned by a
> > person boiled down to "delete all the files in /tmp which
> belong to a
> > specific user when the last process which is running with that UID
> > terminates" (rephrased by me). This got me to thinking. Is there any
> > need for a file in /tmp to exist when there is no process running by
> > a given user?
>
> On a strict reading of the above, you can't rely on a /tmp
> file existing
> "between invocations of the program", in other words when a file isn't
> actively held open by a process. This would break many many shell
> scripts I've read and written over the years :)
I don't see this. When you run a shell script, there is a shell process running
the entire time with your UID. Or did I say it wrong? I didn't mean the file
existed but was closed. I mean a file existed with a given UID and no process
existed in the system anywhere which was using that UID. Although if you run
setuid programs from a script ... I hadn't thought of that. This is why I'm
asking. To avoid a stupid mistake due to my ignorance.
>
> The typical way to clear up /tmp is with the tmpwatch utility, fired
> from cron, which selects files to delete based on their last access
> timestamp. Some distros go further and clean out /tmp completely on
> every boot.
>
> > find /tmp -type f -exec ls -ln {} \; |\ awk '{print $3;}'|\ sort
> > -u|\ while read XUID; do echo Processing UID: $XUID; ps -u $XUID -U
> > $XUID>/dev/null || find /tmp -type f -uid $XUID -exec rm; done
>
> I can see this approach yielding a lot of false negatives;
> i.e. leaving
> files in place because UID has some unrelated process running.
Very true. "Better safe than sorry." in this case. But it will leave a lot of
garbage.
>
> If you're desperate to have a tidy /tmp, a frequent call to tmpwatch
> along these lines might work:
>
> tmpwatch --atime -all --fuser 6 /tmp
>
> This 6-hour deadline is a lot more severe that Redhat's
> default of 10 days.
>
> Before doing that, however, I'd question why the /tmp directory is so
> space-constrained. If software isn't cleaning up its own
> stuff, fix it!
Not always within my power. If user refuses due to lack of time, I can't do
anything other than complain and get told to shut up. We are always short of
space. Space costs money. We have no money. We need the space for long term
data such as databases. Also, my system is not zLinux, but z/OS. I was asking
here because this is where the UNIX wizards hang out. And space management on
z/OS is a whole 'nother beastie. Because management on z/OS is more
parsimonious. We are used to extremely tight control. Having /tmp overallocated
by 1000% for the occasional need is viewed with horror. I can't grow and shrink
filesystems automatically on-the-fly. It's a weird management thing about DASD
space management on z/OS. They don't apply it to our Linux/Intel or Windows
environments. They're used to "slop" over there. I'm held to a higher standard.
> One further trick is to unlink a /tmp file while it's open, which
> guarantees cleanup as soon as the process ends.
I like this, but it is the responsibility of the software. Which I can mention,
but not enforce.
>
>
> Cheers,
> Phil
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
[email protected] * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
