Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 45495 - /etc/cron.daily/tmpwatch does not call tmpwatch with the -s option
/etc/cron.daily/tmpwatch does not call tmpwatch with the -s option
Product: Red Hat Linux
Classification: Retired
Component: tmpwatch (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2001-06-22 03:38 EDT by simon
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-06-22 03:38:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description simon 2001-06-22 03:38:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)

Description of problem:

How reproducible:

Steps to Reproduce:
1.Have an application that creates a file in /tmp but keeps it open
2.wait 10 days


Actual Results:  File deleted

Expected Results:  File should not of been deleted

Additional info:

tmpwatch does not need to use the fuser command, there are API calls to 
determine if a file is open ...
Comment 1 Preston Brown 2001-07-02 14:42:44 EDT
there are no API calls that I know of to determine if a file is open.  The only 
(non-portable) way I know of is to look in /proc/<process-id>/fd/<ids>, which is 
basically what fuser does.  It walks this list and gives you the results.  Problem with 
checking this is that it is racey; any program could open a file after you have already 
checked that PID and then you wouldn't know it because you have already examined 
the FDs for that PID.

Second, it is semantically OK if you remove (unlink) a file if another already has it open.  
The data will still be written correctly. When the process quits, the data will go away.  If 
some program is writing to a file in /tmp less than once every 10 days or so, chances 
are very high that it will not care if tmpwatch unlinks it.

Note You need to log in before you can comment on or make changes to this bug.