Re: clearing out /tmp safely

Tom 'Needs A Hat' Mitchell wrote:

On Fri, Mar 26, 2004 at 07:48:19PM -0600, Robert wrote:

[root@mavis root]# /usr/sbin/tmpwatch 240 /tmp

and I *still* have a bunch of old files in /tmp

[root@mavis root]# find /tmp -ctime +10 | wc -l
  613

....

Y'know, I bet this is gonna turn out to be something really simple that I'm overlooking -- something in the same league as the infamous logrotate problem a few years ago that caused the supply of inodes to dry up in short order.

Try "stat" on these files and dirs there are four interesting dates
when thinking about files.

  Creation: Access: Modify: Change:

I believe that "tmpwatch" is paying attention to the access time
stamp.  So if you inspect a file you are accessing it (cat, wc,
virus-scanner...) and the access time will be reset.

Is that what is going on?

An tmpwatch interaction with the 'access' time and dirs makes sense because of the checking for contents thus:
mkdir /tmp/AAA
stat /tmp/AAA
sleep 60
stat /tmp/AAA
ls /tmp/AAA
stat /tmp/AAA

YES! Using the test file I created...

[root@mavis root]# touch -a -t 198506241213.14 /tmp/zzzA-test-file.txt
[root@mavis root]# stat /tmp/zzzA-test-file.txt
  File: `/tmp/zzzA-test-file.txt'
  Size: 24              Blocks: 8          IO Block: 4096   regular file
Device: 302h/770d       Inode: 214418      Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1985-06-24 12:13:14.000000000 -0500
Modify: 2003-11-14 11:11:37.000000000 -0600
Change: 2004-03-27 06:20:10.000000000 -0600

[root@mavis root]# f-prot /tmp/zzzA-test-file.txt
Virus scanning report  -  27 March 2004 @ 6:20

F-PROT ANTIVIRUS
Program version: 4.3.1
Engine version: 3.14.7

VIRUS SIGNATURE FILES
SIGN.DEF created 26 March 2004
SIGN2.DEF created 26 March 2004
MACRO.DEF created 24 March 2004

Search: /tmp/zzzA-test-file.txt
Action: Report only
Files: Attempt to identify files
Switches: <none>

Results of virus scanning:

Files: 1
MBRs: 0
Boot sectors: 0
Objects scanned: 1

Time: 0:00

No viruses or suspicious files/boot sectors were found.
[root@mavis root]# stat /tmp/zzzA-test-file.txt
  File: `/tmp/zzzA-test-file.txt'
  Size: 24              Blocks: 8          IO Block: 4096   regular file
Device: 302h/770d       Inode: 214418      Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2004-03-27 06:20:40.000000000 -0600
Modify: 2003-11-14 11:11:37.000000000 -0600
Change: 2004-03-27 06:20:10.000000000 -0600

So, f-prot's access is changing the access time and the following shows that tmpwatch is working properly:

[root@mavis root]# touch -a -t 198506241213.14 /tmp/zzzA-test-file.txt
[root@mavis root]# stat /tmp/zzzA-test-file.txt
  File: `/tmp/zzzA-test-file.txt'
  Size: 24              Blocks: 8          IO Block: 4096   regular file
Device: 302h/770d       Inode: 214418      Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1985-06-24 12:13:14.000000000 -0500
Modify: 2003-11-14 11:11:37.000000000 -0600
Change: 2004-03-27 06:30:30.000000000 -0600

[root@mavis root]# /usr/sbin/tmpwatch 240 /tmp
[root@mavis root]# stat /tmp/zzzA-test-file.txt
stat: cannot stat `/tmp/zzzA-test-file.txt': No such file or directory
[root@mavis root]#

Thanks to all who responded and hammered this through my thick old head.

--
People will buy anything that's one to a customer.

 06:33:01  up 2 days, 19:11, 13 users,  load average: 0.00, 0.03, 0.00
     One billion seconds ago it was 05:46:21 CDT Wed 07/19/72

Repeat after me: "The primary purpose of any government
entity is to employ the unemployable."