Bug 45495 - /etc/cron.daily/tmpwatch does not call tmpwatch with the -s option
Summary: /etc/cron.daily/tmpwatch does not call tmpwatch with the -s option
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tmpwatch (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Preston Brown
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-22 07:38 UTC by simon
Modified: 2007-04-18 16:33 UTC (History)
0 users

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

Attachments (Terms of Use)

Description simon 2001-06-22 07:38:27 UTC
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 18:42:44 UTC
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.