Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 3146 - tmpwatch does not delete directories in temporary directories
Summary: tmpwatch does not delete directories in temporary directories
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tmpwatch
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-29 21:24 UTC by vectro
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-08-30 20:28:50 UTC


Attachments (Terms of Use)

Description vectro 1999-05-29 21:24:48 UTC
The tmpwatch manpage says that tmpwatch will delete empty
directories, but I have not found this to be the case. I
don't know if this is because tmpwatch is looking inside
the directories (and thus changing their atime) or for some
other reason.

In any case, this modified /etc/cron.daily/tmpwatch will run
tmpwatch, and then delete any directories under /tmp,
/var/tmp, or /var/catman/cat?. It will only delete whole
directory branches. For example, if find /tmp yields the
following:

/tmp                    (directory)
/tmp/test1              (directory)
/tmp/test1/a            (directory)
/tmp/test1/b            (directory)
/tmp/test2              (directory)
/tmp/test2/a            (directory)
/tmp/test2/a/file       (file)
/tmp/test2/b            (directory)

the script will do rm -rf /tmp/test1 but will leave all of
test2 (including test2/a) alone.

Without further ado, here is the script:

/usr/sbin/tmpwatch 240 --all /tmp /var/tmp /var/catman/cat?
for i in /tmp /var/tmp /var/catman/cat?
do
        for j in ${i}/*
        do
                [ -z "`find $j ! -type d`" ] && rm -rf $j
        done
done

Comment 1 David Lawrence 1999-06-07 19:13:59 UTC
I configured a stock 6.0 machine is the manner reported by the user. I
then ran

/usr/sbin/tmpwatch 0 /tmp /var/tmp /var/catman/cat?

on the command line which is identical to the line in

/etc/cron.daily/tmpwatch

except is set to go off in 0 hours instead of 240 hours. The tmpwatch
script correctly removed all directorys and files properly. This was
tested with tmpwatch-1.7-1

------- Additional Comments From   06/08/99 01:54 -------
I have found that the problem is actualy caused by tmpwatch looking
inside the directories, and thus affecting their atime. This is
unaffected if tmpwatch is looking for directories that are 0 hours
old.
I am currently looking into writing a patch to this. One way to do it
would be to optimize by assuming that a directory with a hard link
count of 2 is empty, but this dosen't work on all filesystems. A
better fix would be to either simply delete all empty directories (as
the patch to the tmpwatch script I provided does), or to notice the
atime for a directory *before* stepping into it.

Comment 2 proux 1999-07-08 08:08:59 UTC
Same thing with tmpwatch-1.7-2, tmpwatch doesn't delete old empty
directories yet ...

Comment 3 Michael K. Johnson 1999-07-30 16:58:59 UTC
Look into this again with 1hr instead of 0hr

Comment 4 Preston Brown 1999-08-30 20:28:59 UTC
I have no problems with 6.0 tmpwatch removing empty directories.
Here's an interactive test run:

[pbrown@dionysus tmpwatch]$ touch -r /boot/map /tmp/testdir
[pbrown@dionysus tmpwatch]$ !stat
stat /tmp/testdir/
  File: "/tmp/testdir/"
  Size: 1024         Filetype: Directory
  Mode: (0775/drwxrwxr-x)         Uid: ( 2180/  pbrown)  Gid: ( 2180/
pbrown)
Device:  3,1   Inode: 32349     Links: 2
Access: Tue Aug 24 16:03:19 1999(00006.00:22:48)
Modify: Tue Aug 24 16:03:19 1999(00006.00:22:48)
Change: Mon Aug 30 16:26:05 1999(00000.00:00:02)
[pbrown@dionysus tmpwatch]$ touch -r /boot/map /tmp/testdir/foo
[pbrown@dionysus tmpwatch]$ stat /tmp/testdir/
  File: "/tmp/testdir/"
  Size: 1024         Filetype: Directory
  Mode: (0775/drwxrwxr-x)         Uid: ( 2180/  pbrown)  Gid: ( 2180/
pbrown)
Device:  3,1   Inode: 32349     Links: 2
Access: Tue Aug 24 16:03:19 1999(00006.00:23:00)
Modify: Mon Aug 30 16:26:15 1999(00000.00:00:04)
Change: Mon Aug 30 16:26:15 1999(00000.00:00:04)
[pbrown@dionysus tmpwatch]$ touch -r /boot/map /tmp/testdir
[pbrown@dionysus tmpwatch]$ stat /tmp/testdir/
  File: "/tmp/testdir/"
  Size: 1024         Filetype: Directory
  Mode: (0775/drwxrwxr-x)         Uid: ( 2180/  pbrown)  Gid: ( 2180/
pbrown)
Device:  3,1   Inode: 32349     Links: 2
Access: Tue Aug 24 16:03:19 1999(00006.00:23:19)
Modify: Tue Aug 24 16:03:19 1999(00006.00:23:19)
Change: Mon Aug 30 16:26:37 1999(00000.00:00:01)
[pbrown@dionysus tmpwatch]$ sudo ./tmpwatch -v 24 /tmp
removing file testdir/foo
removing directory testdir

The file and the directory get removed properly.

6.1 tmpwatch (v2.0) will also support a --atime or --mtime option, so
files may be removed depending on what sort of time you are interested
more in.

Comment 5 William Shubert 2000-06-27 17:49:32 UTC
I'm using RH6.2, and see the same problem - tmpwatch doesn't delete directories,
not ever. I think I know the problem, and the "works for me" above doesn't test
it: every day, tmpwatch scans the /tmp tree for files to remove. That means that
every day, the "atime" of every directory of /tmp gets updated. Since tmpwatch
as configured by RH6.2 doesn't delete a directory until it's atime is 7 days
old, that means directories simply never get deleted.

For tmpwatch to be useful for deleting directories, it can *never* use atime. It
at the very least needs to add a switch for "use atime for files, mtime for
directories". Or maybe a switch for "delete empty directories with a ctime of
over 7 days"...that way, the directory will last until they have been around for
seven days and are empty, which seems a good criteria for removal.



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