clearing out /tmp safely

Robert kerplop at sbcglobal.net
Sat Mar 27 12:37:56 UTC 2004


Tom 'Needs A Hat' Mitchell wrote:
> On Fri, Mar 26, 2004 at 07:48:19PM -0600, Robert wrote:
> 
>>>>[root at mavis root]# /usr/sbin/tmpwatch 240 /tmp
>>>>
>>>>and I *still* have a bunch of old files in /tmp
>>>>
>>>>[root at 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 at mavis root]# touch -a -t 198506241213.14 /tmp/zzzA-test-file.txt
[root at 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 at 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 at 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 at mavis root]# touch -a -t 198506241213.14 /tmp/zzzA-test-file.txt
[root at 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 at mavis root]# /usr/sbin/tmpwatch 240 /tmp
[root at mavis root]# stat /tmp/zzzA-test-file.txt
stat: cannot stat `/tmp/zzzA-test-file.txt': No such file or directory
[root at 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."






More information about the fedora-list mailing list