Many Linux installations use "tmpfs" for /tmp. Personally, I do that as a rule. (All rules are subject to exception, and I do that too.)
The advantage of tmpfs is that it magically cleans up every time you reboot. You can get the same effect from explicit deletion of /tmp contents when the system comes up. That bit me a year ago ... I think it was Kubuntu. Irritating! I knew the box was not using tmpfs for /tmp, so I expected the content to remain. But like your users, after learning one time I stopped leaving clutter in /tmp on that system. (I have been following the MVS-OE thread too.) Rebooting is the most common catastrophic event that happens to a computer system on a regular basis. It is therefore the most natural choice for /tmp cleanup trigger. About your proposed 'find' pipeline, there are A LOT of reasons why people use /tmp. Just because the owner of a file is not presently logged on does not mean either that they are ignorant (of the intent of /tmp) or forgetful (that they left something there). /tmp is commonly used as a staging area. In any case, I would not do per-UID selective removal (unless that user has been deleted). Some people go with file age selection to clean up /tmp, but don't use mod time for that. (Some of us are insistent on retaining mod times, so the mod time DOES NOT have any bearing on when a file landed under /tmp.) Whatever means you employ, someone almost certainly WILL get bitten. Your phone will ring. But you need to stop their bad behavior. You will have to exercise "managerial courage", bite the bullet, pull the trigger, get er done. I have refrained from jumping in on the MVS-OE thread. I recommend that you be judicious and selective about the USS-specific methods you employ. Some of the features of USS are excellent and really helpful. But where they vary from the POSIX standard you may have interoperability issues and you WILL have sysadmin education requirements. Same thing happens in Linux. (To that point, for example, I advise people to back off from BASHisms in their shell scripts ... if they ever want to use said scripts on USS or OpenVM or Solaris or ... whatever.) In other words, whatever you do, try to use common Unix tools if you can. Looks like other responses are pouring in already. -- R; <>< Rick Troth Velocity Software http://www.velocitysoftware.com/ On Fri, Mar 11, 2011 at 09:23, McKown, John <[email protected]> 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. 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? IOW, can some process be dependant on > a file in /tmp which is owned by a UID other than its own UID (and/or maybe > 0). Or rephrasing again. If I have a cron entry remove all the files in /tmp > which are owned by a given UID (not 0) when there are no processes running > with that UID, could this cause a problem? If you prefer an example, what if > I run the following script daily by root: > > 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 > > Perhaps I should do an "lsof" to see if the file is "in use" before doing the > "rm" on it? And the script needs to be made more efficient. I don't like > doing two find commands. > > -- > 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/ > ---------------------------------------------------------------------- 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/
