Bug 468670 - /tmp directory's size increases
/tmp directory's size increases
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: tmpwatch (Show other bugs)
16
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Miloslav Trmač
Fedora Extras Quality Assurance
: Reopened
: 755681 (view as bug list)
Depends On: 810257
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-27 07:30 EDT by yn
Modified: 2013-02-13 21:34 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 21:34:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
add --dirmtime flag to tmpwatch commands in /etc/cron.daily/tmpwatch (902 bytes, patch)
2011-08-02 13:34 EDT, Robert K. Moniot
no flags Details | Diff

  None (edit)
Description yn 2008-10-27 07:30:23 EDT
Description of problem:
/tmp directory's size increases

Version-Release number of selected component (if applicable):
tmpwatch-2.9.13-2.x86_64
gvfs-0.2.5-1.fc9.x86_64
gvfs-fuse-0.2.5-1.fc9.x86_64

How reproducible:
The issue is occurred now.

Description:
I thought that tmpwatch(/etc/cron.daily/tmpwatch) is deleted files
and directories in /tmp.
But the tmpwatch have deleting files and directories.

I examined the issue by the following command in 2008-10-27.
 - # ls -lu /tmp
 - # lsof /tmp/<file/directory>

Could you please answer the following auestions?

1. Does the files and directories delete? 
2. Does flags of /etc/cron.daily/tmpwatch script rewrite?
    (flags=-umc ==> flags=-mc)
3. Is the issue problem of gvfs?

# date
==============
Mon Oct 27 20:23:52 JST 2008
==============

# ls -lu
==========================================
...
rwx------ 2 adminrooter adminrooter     4096 1970-01-01 09:00 orbit-adminrooter
drwx------ 2 gdm         gdm             4096 2008-10-27 13:28 orbit-gdm
-rw------- 1 adminrooter adminrooter 26195322 2008-10-27 12:58 os+dRfbh.zip.part
drwxrwxr-x 3 adminrooter adminrooter     4096 2008-10-27 13:28 pdfdownload
drwx------ 2 adminrooter adminrooter     4096 2008-10-27 13:28 plugtmp
drwx------ 2 adminrooter adminrooter     4096 2008-10-27 16:17 plugtmp-1
drwx------ 2 adminrooter adminrooter     4096 2008-10-27 13:28 pulse-adminrooter
drwx------ 2 gdm         gdm             4096 2008-10-27 13:28 pulse-gdm
...
-rw------- 1 root        root         5158404 2008-10-27 12:58 tmp.UnoGPBgCd6
-rw------- 1 adminrooter adminrooter    35013 2008-10-27 12:58 tmpU_VmqI
-rw------- 1 root        root         5862900 2008-10-27 12:58 tmp.vSnURGSGsV
-rw------- 1 adminrooter adminrooter    40058 2008-10-27 12:58 tmpZNsARO
drwx------ 2 adminrooter adminrooter     4096 2008-10-27 13:28 virtual-adminrooter.09ahjx
drwx------ 2 adminrooter adminrooter     4096 2008-10-27 13:28 virtual-adminrooter.0aaqAp
drwx------ 2 adminrooter adminrooter     4096 2008-10-27 13:28 virtual-adminrooter.0bQUbZ
drwx------ 2 adminrooter adminrooter     4096 2008-10-27 13:28 virtual-adminrooter.1mWd6n
...
==========================================

# lsof tmp.UnoGPBgCd6
  * All files and directories output the command.
======================
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/adminrooter/.gvfs
      Output information may be incomplete.
======================
Comment 1 Miloslav Trmač 2008-10-27 13:27:01 EDT
Thanks for your report.

I'm afraid I have some trouble understanding your report.  What is the problem you are trying to report?  What is not working and what should be different?

To try to answer your questions:
> 1. Does the files and directories delete?
I can't understand the question.  Just guessing - the files in your (ls -lu) output are not deleted because they were last accessed on 2008-10-27, and tmpwatch is configured to only remove much older files by default?

> 2. Does flags of /etc/cron.daily/tmpwatch script rewrite?
>    (flags=-umc ==> flags=-mc)
No, that can lead to data loss.
> 3. Is the issue problem of gvfs?
The error message printed by lsof is completely unrelated to tmpwatch.
Comment 2 yn 2008-10-28 01:45:49 EDT
Thank you for your kind support.

Now, the trouble has not occurred about the problem.
But /tmp directory's size have increasing everyday.

about question 1:
There are 105 "virtual-<USERNAME>-***" directories in /tmp directory.
(the directories is empty.)
The directory automatically is made when I was login.
And access time of all the directories updated.
Thus, the directories is not deleted by tmpwatch and have increasing (size and number of directories).

Does increasing "virtual-<USERNAME>-***" directories specifications?

best regards.
Comment 3 Leam 2009-02-07 07:15:31 EST
Similar issue on F10. Lots of these in /tmp:

virtual-leam.smIwbD
virtual-leam.uAbKfC
virtual-leam.uT4qIp
virtual-leam.Wj0Epp
virtual-leam.xjgWk5
virtual-leam.yKXxeh
virtual-leam.YN10p4
virtual-leam.Z3DOEi
virtual-leam.zGGw0P
virtual-leam.ZpXzDX
 
That get made on gnome login but not cleaned up. Need help identifying the offending program so I can chat with them about house-keeping.

Leam
Comment 4 Bug Zapper 2009-06-09 23:05:39 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Miloslav Trmač 2009-06-10 08:36:30 EDT
I have tried to identify the program on earlier releases, and failed.

Let's see if this is happening in F11 as well...
Comment 6 Tom London 2009-06-30 18:25:44 EDT
I may be seeing a similar issue with Rawhide (tmpwatch-2.9.15-1.x86_64): lots of files that don't seem to get deleted from /tmp.

First, my /etc/cron.daily/tmpwatch says:

[root@tlondon ~]# cat /etc/cron.daily/tmpwatch 
#! /bin/sh
flags=-umc
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
	-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix 10d /tmp
/usr/sbin/tmpwatch "$flags" 30d /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
    if [ -d "$d" ]; then
	/usr/sbin/tmpwatch "$flags" -f 30d "$d"
    fi
done
[root@tlondon ~]# 

If I read this correctly, files older than 10 days should be deleted from /tmp (except for the excluded ones).  Right?

But, I am seeings an overabundance of /tmp/kerneloops.XXXXX files, and since today is 6-30,

[tbl@tlondon tmp]$ ls -lrt /tmp
total 448
-rw-------. 1 tbl  tbl  1310 2009-06-08 14:54 bug-buddy-Q5NQUU
-rw-r--r--. 1 root root 1880 2009-06-09 06:20 kerneloops.IQ6Mka
-rw-r--r--. 1 root root 2260 2009-06-09 06:20 kerneloops.uPwqCm
-rw-r--r--. 1 root root 1018 2009-06-09 07:19 kerneloops.vXdQPp
-rw-r--r--. 1 root root 1225 2009-06-09 07:19 kerneloops.QY4GrX
-rw-r--r--. 1 root root  399 2009-06-09 08:49 kerneloops.pAGhLI
-rw-r--r--. 1 root root 1902 2009-06-09 14:30 kerneloops.rrz9A8
-rw-r--r--. 1 root root 2299 2009-06-09 14:30 kerneloops.iGrPCv
-rw-r--r--. 1 root root 1667 2009-06-10 06:25 kerneloops.xs6Qso
-rw-r--r--. 1 root root 2076 2009-06-10 06:25 kerneloops.M6zk6M
-rw-r--r--. 1 root root 1667 2009-06-10 06:31 kerneloops.zb6eXZ
-rw-r--r--. 1 root root 1865 2009-06-10 06:55 kerneloops.rfFnrF
-rw-r--r--. 1 root root 2069 2009-06-10 06:55 kerneloops.jp2d2i
-rw-r--r--. 1 root root 2334 2009-06-10 07:02 kerneloops.zyLm0l
-rw-r--r--. 1 root root 2540 2009-06-10 07:02 kerneloops.mmxAEY
-rw-r--r--. 1 root root 1708 2009-06-10 08:21 kerneloops.XW0pgI
-rw-r--r--. 1 root root 1906 2009-06-10 08:22 kerneloops.ar4hMl
-rw-r--r--. 1 root root 1011 2009-06-10 08:43 kerneloops.cWwODG
-rw-r--r--. 1 root root 1208 2009-06-10 08:43 kerneloops.xkfrIN
-rw-r--r--. 1 root root 1864 2009-06-11 06:35 kerneloops.RKHfXH
-rw-r--r--. 1 root root 2060 2009-06-11 06:35 kerneloops.cdsjnp
-rw-r--r--. 1 root root 1415 2009-06-11 07:38 kerneloops.9Uk5ik
-rw-r--r--. 1 root root 1604 2009-06-11 07:38 kerneloops.3DtXnH
-rw-r--r--. 1 root root 1129 2009-06-11 07:45 kerneloops.f8eHTy
-rw-r--r--. 1 root root 1313 2009-06-11 07:46 kerneloops.bIZQ95
-rw-r--r--. 1 root root 2641 2009-06-12 06:20 kerneloops.cmukmA
-rw-r--r--. 1 root root 2824 2009-06-12 06:21 kerneloops.7j6ehE
-rw-r--r--. 1 root root 2641 2009-06-12 07:00 kerneloops.kvMYX1
-rw-r--r--. 1 root root 1481 2009-06-12 08:32 kerneloops.KSe8VD
-rw-r--r--. 1 root root 2950 2009-06-12 08:33 kerneloops.L2m63v
-rw-r--r--. 1 root root 1497 2009-06-15 06:16 kerneloops.vdeS3V
-rw-r--r--. 1 root root 2982 2009-06-15 06:16 kerneloops.NHKRpj
-rw-r--r--. 1 root root 1497 2009-06-15 07:05 kerneloops.o9DW4L
-rw-r--r--. 1 root root 3169 2009-06-15 07:06 kerneloops.OXEFeN
-rw-r--r--. 1 root root 1497 2009-06-15 07:10 kerneloops.juYCHB
-rw-r--r--. 1 root root 3175 2009-06-15 07:10 kerneloops.WDcQzs
-rw-r--r--. 1 root root  184 2009-06-15 08:56 kerneloops.4NXXK4
-rw-r--r--. 1 root root 1497 2009-06-16 06:11 kerneloops.IaVxqT
-rw-r--r--. 1 root root 3169 2009-06-16 06:11 kerneloops.nQ4nIY
-rw-r--r--. 1 root root  184 2009-06-16 12:58 kerneloops.X0rdoT
-rw-r--r--. 1 root root 1481 2009-06-17 06:14 kerneloops.5yGUnh
-rw-r--r--. 1 root root 3143 2009-06-17 06:15 kerneloops.ujiMA7
-rw-r--r--. 1 root root  184 2009-06-17 12:44 kerneloops.inOnGe
-rw-r--r--. 1 root root 1481 2009-06-17 21:39 kerneloops.7WeHWA
-rw-r--r--. 1 root root 3134 2009-06-17 21:40 kerneloops.DELSVg
-rw-r--r--. 1 root root 1534 2009-06-17 21:49 kerneloops.cc46A7
-rw-r--r--. 1 root root 3056 2009-06-17 21:49 kerneloops.lH71Hp
-rw-r--r--. 1 root root 1481 2009-06-18 06:09 kerneloops.W7WGtB
-rw-r--r--. 1 root root 2950 2009-06-18 06:09 kerneloops.JtyO5U
-rw-r--r--. 1 root root 1534 2009-06-18 06:48 kerneloops.FTEAuI
-rw-r--r--. 1 root root 1534 2009-06-18 06:52 kerneloops.dfFCvd
-rw-r--r--. 1 root root 3056 2009-06-18 06:52 kerneloops.GShw3C
-rw-r--r--. 1 root root 1534 2009-06-18 07:01 kerneloops.OGf48G
-rw-r--r--. 1 root root 1481 2009-06-19 06:15 kerneloops.NhQ9ci
-rw-r--r--. 1 root root 3137 2009-06-19 06:16 kerneloops.LC0emz
-rw-r--r--. 1 root root 1399 2009-06-19 07:19 kerneloops.Kff4sH
-rw-r--r--. 1 root root 1411 2009-06-19 07:26 kerneloops.1jGP6j
-rw-r--r--. 1 root root 1497 2009-06-19 07:35 kerneloops.pWOARR
-rw-r--r--. 1 root root 3552 2009-06-19 07:35 kerneloops.IzVCjL
-rw-r--r--. 1 root root 1497 2009-06-19 07:42 kerneloops.npKvci
-rw-r--r--. 1 root root 3166 2009-06-19 07:42 kerneloops.eUs2f2
-rw-r--r--. 1 root root 1497 2009-06-19 07:50 kerneloops.Wh70XC
-rw-r--r--. 1 root root 2982 2009-06-19 07:50 kerneloops.nnI2e5
-rw-r--r--. 1 root root  202 2009-06-19 08:59 kerneloops.2gmXxs
-rw-r--r--. 1 root root 1402 2009-06-19 17:55 kerneloops.b0e0pI
-rw-r--r--. 1 root root 1402 2009-06-20 09:31 kerneloops.TtkCtL
-rw-r--r--. 1 root root 1402 2009-06-20 17:04 kerneloops.rk0tAi
-rw-r--r--. 1 root root 1411 2009-06-20 17:14 kerneloops.LxJxkj
-rw-r--r--. 1 root root 1446 2009-06-20 17:26 kerneloops.2jKgRs
-rw-r--r--. 1 root root 3452 2009-06-20 17:26 kerneloops.vxKbUs
-rw-r--r--. 1 root root 1402 2009-06-20 17:29 kerneloops.clkgRA
-rw-r--r--. 1 root root 3566 2009-06-20 17:30 kerneloops.TsKjVf
-rw-r--r--. 1 root root 1402 2009-06-21 12:56 kerneloops.utDIrh
-rw-r--r--. 1 root root 1399 2009-06-21 16:39 kerneloops.fzVeHZ
-rw-r--r--. 1 root root 1411 2009-06-21 16:54 kerneloops.LWC3u9
-rw-r--r--. 1 root root 5436 2009-06-21 16:54 kerneloops.HVN5R1
-rw-r--r--. 1 root root 1402 2009-06-21 17:12 kerneloops.iHYsAO
-rw-r--r--. 1 root root 1402 2009-06-22 06:15 kerneloops.l8sNmb
-rw-r--r--. 1 root root  196 2009-06-22 07:08 kerneloops.mOBGkc
-rw-r--r--. 1 root root  199 2009-06-22 08:31 kerneloops.m2hrXE
-rw-r--r--. 1 root root  202 2009-06-23 06:05 kerneloops.KFcd6e
-rw-r--r--. 1 root root  202 2009-06-23 06:31 kerneloops.kT2sVd
-rw-r--r--. 1 root root 2157 2009-06-24 06:46 kerneloops.0eUJy1
-rw-r--r--. 1 root root  195 2009-06-24 06:51 kerneloops.rTRgmT
-rw-r--r--. 1 root root  202 2009-06-24 07:05 kerneloops.9X3PK5
drwx------. 2 tbl  tbl  4096 2009-06-24 12:32 keyring-JOX0Yn
-rw-r--r--. 1 root root 2310 2009-06-25 06:17 kerneloops.TrUMCe
-rw-r--r--. 1 root root  195 2009-06-25 06:39 kerneloops.SSti4O
-rw-r--r--. 1 root root  202 2009-06-25 08:39 kerneloops.7YUU7n
-rw-rw-r--. 1 tbl  tbl   222 2009-06-25 17:07 tag
-rw-r--r--. 1 root root 2165 2009-06-26 06:45 kerneloops.S9fIHI
-rw-r--r--. 1 root root 2305 2009-06-26 19:07 kerneloops.dwlEgz
-rw-r--r--. 1 root root  244 2009-06-26 21:37 kerneloops.65R1TA
-rw-r--r--. 1 root root  196 2009-06-26 22:08 kerneloops.JZyt2V
-rw-r--r--. 1 root root  196 2009-06-27 07:28 kerneloops.5DZhiq
-rw-r--r--. 1 root root 2293 2009-06-27 15:17 kerneloops.xU28uk
-rw-r--r--. 1 root root  193 2009-06-28 09:27 kerneloops.TMi41Y
drwx------. 2 tbl  tbl  4096 2009-06-29 11:07 keyring-mFMf0f
-rw-r--r--. 1 root root  201 2009-06-29 11:08 kerneloops.6HtFRo
-rw-r--r--. 1 root root  196 2009-06-29 12:37 kerneloops.6lBiID
drwx------. 2 tbl  tbl  4096 2009-06-30 06:26 keyring-pYbiTk
-rw-r--r--. 1 root root  446 2009-06-30 06:26 kerneloops.gWxaXL
-rw-r--r--. 1 root root  195 2009-06-30 08:22 kerneloops.hIjjTg
drwx------. 2 gdm  gdm  4096 2009-06-30 09:35 orbit-gdm
drwx------. 2 tbl  tbl  4096 2009-06-30 09:35 keyring-nsuCBh
drwx------. 2 tbl  tbl  4096 2009-06-30 09:36 pulse-gS3sA0AmIfIf
drwx------. 2 tbl  tbl  4096 2009-06-30 09:36 virtual-tbl.9jufOB
-rw-r--r--. 1 root root  444 2009-06-30 09:36 kerneloops.BwZ2GR
drwx------. 2 gdm  gdm  4096 2009-06-30 09:36 pulse-1RJpWMqe5HK9
drwxr-xr-x. 2 tbl  tbl  4096 2009-06-30 14:50 audacity-tbl
drwx------. 2 tbl  tbl  4096 2009-06-30 15:17 orbit-tbl
[tbl@tlondon tmp]$ 

Running the "tmpwatch" command manually, I get:

[root@tlondon ~]# /usr/sbin/tmpwatch -v -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix 10d /tmp
removing directory /tmp/orbit-tbl if empty
[root@tlondon ~]# 

and nothing appears deleted.

Am I confused on how this is supposed to work?
Comment 7 Tom London 2009-06-30 19:03:16 EDT
Ah.... "ls -lurt" shows something different:

[root@tlondon ~]# ls -lurt /tmp
total 448
drwx------. 2 tbl  tbl  4096 1969-12-31 16:00 orbit-tbl
-rw-r--r--. 1 root root  202 2009-06-27 18:38 kerneloops.7YUU7n
-rw-r--r--. 1 root root 3169 2009-06-27 18:38 kerneloops.OXEFeN
-rw-r--r--. 1 root root 3143 2009-06-27 18:38 kerneloops.ujiMA7
-rw-rw-r--. 1 tbl  tbl   222 2009-06-27 18:38 tag
-rw-r--r--. 1 root root 2299 2009-06-27 18:38 kerneloops.iGrPCv
-rw-r--r--. 1 root root 3169 2009-06-27 18:38 kerneloops.nQ4nIY
-rw-r--r--. 1 root root 1534 2009-06-27 18:38 kerneloops.cc46A7
-rw-r--r--. 1 root root 2950 2009-06-27 18:38 kerneloops.JtyO5U
-rw-r--r--. 1 root root 1497 2009-06-27 18:38 kerneloops.vdeS3V
-rw-r--r--. 1 root root 1208 2009-06-27 18:38 kerneloops.xkfrIN
-rw-r--r--. 1 root root 3137 2009-06-27 18:38 kerneloops.LC0emz
-rw-r--r--. 1 root root 1402 2009-06-27 18:38 kerneloops.TtkCtL
-rw-r--r--. 1 root root 2982 2009-06-27 18:38 kerneloops.NHKRpj
-rw-r--r--. 1 root root 1402 2009-06-27 18:38 kerneloops.utDIrh
-rw-r--r--. 1 root root 2069 2009-06-27 18:38 kerneloops.jp2d2i
-rw-r--r--. 1 root root 1402 2009-06-27 18:38 kerneloops.l8sNmb
-rw-r--r--. 1 root root 1225 2009-06-27 18:38 kerneloops.QY4GrX
-rw-r--r--. 1 root root 2076 2009-06-27 18:38 kerneloops.M6zk6M
-rw-r--r--. 1 root root  184 2009-06-27 18:38 kerneloops.4NXXK4
-rw-r--r--. 1 root root  399 2009-06-27 18:38 kerneloops.pAGhLI
-rw-r--r--. 1 root root 2824 2009-06-27 18:38 kerneloops.7j6ehE
-rw-r--r--. 1 root root 1906 2009-06-27 18:38 kerneloops.ar4hMl
-rw-r--r--. 1 root root 3134 2009-06-27 18:38 kerneloops.DELSVg
-rw-r--r--. 1 root root 2641 2009-06-27 18:38 kerneloops.kvMYX1
-rw-r--r--. 1 root root 1481 2009-06-27 18:38 kerneloops.W7WGtB
-rw-r--r--. 1 root root 1667 2009-06-27 18:38 kerneloops.xs6Qso
-rw-r--r--. 1 root root 1667 2009-06-27 18:38 kerneloops.zb6eXZ
-rw-r--r--. 1 root root 1497 2009-06-27 18:38 kerneloops.juYCHB
-rw-r--r--. 1 root root 1411 2009-06-27 18:38 kerneloops.LxJxkj
-rw-r--r--. 1 root root 1864 2009-06-27 18:38 kerneloops.RKHfXH
-rw-r--r--. 1 root root 2060 2009-06-27 18:38 kerneloops.cdsjnp
-rw-r--r--. 1 root root 1481 2009-06-27 18:38 kerneloops.5yGUnh
-rw-r--r--. 1 root root 1880 2009-06-27 18:38 kerneloops.IQ6Mka
-rw-r--r--. 1 root root  199 2009-06-27 18:38 kerneloops.m2hrXE
-rw-r--r--. 1 root root 2260 2009-06-27 18:38 kerneloops.uPwqCm
-rw-r--r--. 1 root root 1902 2009-06-27 18:38 kerneloops.rrz9A8
-rw-r--r--. 1 root root 1497 2009-06-27 18:38 kerneloops.o9DW4L
-rw-r--r--. 1 root root 1481 2009-06-27 18:38 kerneloops.7WeHWA
-rw-r--r--. 1 root root 1534 2009-06-27 18:38 kerneloops.dfFCvd
-rw-r--r--. 1 root root 1604 2009-06-27 18:38 kerneloops.3DtXnH
-rw-r--r--. 1 root root  202 2009-06-27 18:38 kerneloops.9X3PK5

Damn.... Something is accessing these files....

Never mind.....
Comment 8 Tom London 2009-06-30 19:04:18 EDT
Yeah, running with just the '-c' option shows the files being deletes.
Comment 9 Victoria A Smith 2009-10-27 16:22:17 EDT
F10 (and RHEL5.4) behavior seems to deviate from the behavior described in the man pages.  Although man reads like the u, m and c flags are exclusive:

  tmpwatch [-u|-m|-c] 

under DESCRIPTION it states "If the --atime, --ctime or --mtime options are used in combination, the decision about deleting a file will be based on the maximum of these times."  tmpwatch does not seem to follow this description:

$ ls -lt /tmp
[...]
-rw-rw-r-- 1 vasmith vasmith 138887 2009-06-03 15:33 ts-entries.png

$ ls -lc /tmp
[...]
-rw-rw-r-- 1 vasmith vasmith 138887 2009-10-27 14:06 ts-entries.png

$ date
Tue Oct 27 14:12:36 MDT 2009

$ sudo /usr/sbin/tmpwatch -umc -v -v -t -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix 10d /tmp
[...]
found directory entry ts-entries.png
taking as significant time: Tue Oct 27 14:06:49 2009

The "maximum of these times" implies the oldest time to me, i.e., the 2009-06-03 timestamp.

Victoria
Comment 10 Miloslav Trmač 2009-10-29 09:53:50 EDT
The paragraph that contains the "maximum of these times" sentence talks about --atime, --ctime and --mtime; "maximum of ... times" IMHO implies the latest time.

The paragraph not talk about the threshold for removing times, that is discussed in the following paragraph.

In any case, this is the intended behavior: the goal is to err on the side of caution, not removing files if there is any reason to keep them.
Comment 11 Bug Zapper 2010-04-27 08:17:50 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Miloslav Trmač 2010-04-28 10:06:06 EDT
Still seeing this at least for /tmp/virtual-*, /tmp/haze-*.
Comment 13 Tom London 2010-04-28 10:11:58 EDT
Yeah, I continue to have this in my /etc/rc.d/rc.local:

# clean up /tmp from misbehaving apps
rm -rf /tmp/haze-* /tmp/virtual-* /tmp/plugtmp*
Comment 14 Thomas Moschny 2010-07-23 05:59:50 EDT
Could be the missing -f switch is the cause for some files and directories not being deleted?

The manpage of tmpwatch says:

   -f, --force
       Remove files even if root doesn’t have write access (akin to rm -f).

Also, one could think of setting -a:

   -a, --all
       Remove all file types, not just regular files, symbolic links and directories.

I'd suggest at least setting -f.
Comment 15 Miloslav Trmač 2010-07-23 09:41:17 EDT
No, -f affects only files owned by root.

The problematic files I see are owned by a regular user, and their timestamp keeps being updated.
    Mirek
Comment 16 Thomas Moschny 2010-07-23 10:13:37 EDT
(In reply to comment #15)
> No, -f affects only files owned by root.

That seems to be not true. Where did you get that?

For example /tmp/virtual-* was mentioned. They are owned by some user!=root, and have permissions 700. And these are only removed when -f is specified.
Comment 17 Miloslav Trmač 2010-07-23 10:24:15 EDT
>        if (!sb.st_uid && !(flags & FLAG_FORCE) && !(sb.st_mode & S_IWUSR)) {
// then don't delete the file

This is the only line in the tmpwatch source code related to '-f'.
Comment 18 Thomas Moschny 2010-07-23 11:26:37 EDT
(In reply to comment #17)
> >        if (!sb.st_uid && !(flags & FLAG_FORCE) && !(sb.st_mode & S_IWUSR)) {
> // then don't delete the file
> 
> This is the only line in the tmpwatch source code related to '-f'.    

Ok, but then please update the manpage.
Comment 19 Miloslav Trmač 2010-07-23 12:27:54 EDT
(In reply to comment #18)
> (In reply to comment #17)
> > >        if (!sb.st_uid && !(flags & FLAG_FORCE) && !(sb.st_mode & S_IWUSR)) {
> > // then don't delete the file
> > 
> > This is the only line in the tmpwatch source code related to '-f'.    
> 
> Ok, but then please update the manpage.    

Good point, fixed upstream.
Comment 20 Bug Zapper 2011-06-02 14:26:05 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 Bug Zapper 2011-06-27 10:01:05 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 22 Miloslav Trmač 2011-06-27 11:01:01 EDT
Still seeing this on F15, e.g. /tmp/virtual-*, /tmp/gnash-cookies.*
Comment 23 Robert K. Moniot 2011-08-02 13:28:32 EDT
We have been seeing similar behavior: old directories not getting deleted when it seems they should be.  (We are running a mix of F14 and F15 systems and it seems to be the same in both.)

I could be wrong, but I *think* the problem is the lack of --dirmtime flag in the tmpwatch command.  Since tmpwatch uses the latest of mtime, atime, and ctime, anything that descends the directory will update the atime and make the directory appear recently used.

Note there is also bug 694838 - tmpwatch doesn't clean up sockets which prevents dirs containing sockets from being removed.
Comment 24 Robert K. Moniot 2011-08-02 13:34:55 EDT
Created attachment 516373 [details]
add --dirmtime flag to tmpwatch commands in /etc/cron.daily/tmpwatch

Patch for /etc/cron.daily/tmpwatch to add the --dirmtime flag.  It has not undergone much testing, so use with caution.
Comment 25 Miloslav Trmač 2011-08-02 13:39:11 EDT
(In reply to comment #23)
> I could be wrong, but I *think* the problem is the lack of --dirmtime flag in
> the tmpwatch command.  Since tmpwatch uses the latest of mtime, atime, and
> ctime, anything that descends the directory will update the atime and make the
> directory appear recently used.
The above description is correct, but I don't think it explains the problem:

- Nothing is supposed to descend the directories - they have random names.  The only exception is locate's updatedb, which takes care to reset atime to its original value (changing ctime in the process, but tmpwatch does _not_ use ctime of directories).

- The problem happens even for regular files directly in /tmp - comment #7 lists /tmp/kerneloops.*


As far as I can tell, some program runs at irregular intervals (definitely less than once a day), and opens every file in /tmp.  I don't know what the program is, although I haven't spent too much effort on tracking it down; e.g. setting up an audit rules for some of the files might be helpful.
Comment 26 Robert K. Moniot 2011-08-02 14:44:33 EDT
Those are good points.  Still, there may be different reasons for different things not being deleted, e.g. the problem with sockets is unrelated to this one.  There could be a different explanation for the regular files like kerneloops.* than for directories.

At any rate, it seems that adding --dirmtime can't hurt, and it does cause some directories to be removed that were not being removed before.
Comment 27 Miloslav Trmač 2011-08-02 15:40:12 EDT
(In reply to comment #26)
> At any rate, it seems that adding --dirmtime can't hurt, and it does cause some
> directories to be removed that were not being removed before.
The promise of tmpwatch is, first of all, to do no harm - i.e. not to remove anything that is being used, and --dirmtime is counter to this.

Having files left around is not good - but removing used files would be much worse.
Comment 28 Miloslav Trmač 2011-11-21 15:16:40 EST
*** Bug 755681 has been marked as a duplicate of this bug. ***
Comment 29 Michael Cronenworth 2012-04-03 14:10:31 EDT
stat before tmpwatch:
  File: `/tmp/emacs502/'
...
Modify: 2011-06-06 15:53:14.000000000 -0500
Change: 2012-04-03 03:22:59.262143608 -0500

stat after tmpwatch:
  File: `/tmp/emacs502/'
...
Modify: 2011-06-06 15:53:14.000000000 -0500
Change: 2012-04-03 13:05:41.634733397 -0500

/tmp/emacs502 is an empty directory. I don't use emacs, but must have in the past one time.

Is tmpwatch looking at the change time? If so, tmpwatch itself is keeping directories around.
Comment 30 Miloslav Trmač 2012-04-03 14:16:05 EDT
(In reply to comment #29)
> stat before tmpwatch:
> Modify: 2011-06-06 15:53:14.000000000 -0500
> Change: 2012-04-03 03:22:59.262143608 -0500
> 
> stat after tmpwatch:
> Modify: 2011-06-06 15:53:14.000000000 -0500
> Change: 2012-04-03 13:05:41.634733397 -0500
> 
> Is tmpwatch looking at the change time?

No:
>       -c, --ctime
>              Make the decision about deleting a  file  based  on  the  file's
>              ctime (inode change time) instead of the atime; for directories,
>              make the decision based on the mtime.

Also see comment #25 - the updates are not daily.
Comment 31 Michael Cronenworth 2012-04-04 12:48:28 EDT
(In reply to comment #30)
> Also see comment #25 - the updates are not daily.

OK. Then this seems to be a pretty clear indication of what is doing the accessing:

Stat of /tmp/emacs502:
Access: 2012-04-04 08:51:26.961371119 -0500

/var/log/messages:
Apr  4 08:51:26 mcronenworth systemd-tmpfiles[10412]: Successfully loaded SELinux database in 8ms 859us, size on heap is 484K.
Comment 32 Miloslav Trmač 2012-04-05 09:14:18 EDT
(In reply to comment #31)
> (In reply to comment #30)
> > Also see comment #25 - the updates are not daily.
> 
> OK. Then this seems to be a pretty clear indication of what is doing the
> accessing:
> 
> Stat of /tmp/emacs502:
> Access: 2012-04-04 08:51:26.961371119 -0500
> 
> /var/log/messages:
> Apr  4 08:51:26 mcronenworth systemd-tmpfiles[10412]: Successfully loaded
> SELinux database in 8ms 859us, size on heap is 484K.

Good catch, that is definitely the current culprit - directory atime is updated on each systemd-tmpfiles run.

Looking at the history of the bug report (original report was filed before systemd was included, and again comment #25), there must have been a different cause.

However, for directories such a cause is currently masked by systemd-tmpfiles, and on my system I don't currently have any non-directory suggesting that the problem still persists.

Can anyone else find a regular file in /tmp that has a more recent atime or ctime than it should?
Comment 33 David Juran 2012-06-12 05:14:49 EDT
I just found a directory that is only readable by root in /tmp which contains files which havenät been looked at for some year...
This is Fedora 16 with tmpwatch-2.10.3-1.fc16.x86_64
Comment 34 Michael Cronenworth 2012-06-12 09:25:42 EDT
David, see comment 31. Per bug 810257 the very latest systemd package fixes the access time issue. After updating you will need to wait 10 days for the files/folders to be removed by tmpwatch.

I believe this bug can now be closed.
Comment 35 David Juran 2012-08-01 07:32:48 EDT
No, problem still remains:

[djuran@localhost ~]$ rpm -qi systemd
Name        : systemd
Version     : 37
Release     : 25.fc16
Architecture: x86_64
Install Date: mån 11 jun 2012 08.48.42

So more then 10 days ago.

[djuran@localhost ~]$ sudo stat /tmp/localhost-20090803162552/etc/mail/helpfile
  File: `/tmp/localhost-20090803162552/etc/mail/helpfile'
  Size: 5584      	Blocks: 24         IO Block: 4096   regular file
Device: fd03h/64771d	Inode: 2853082     Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:user_tmp_t:SystemLow
Access: 2009-08-03 15:31:31.000000000 +0200
Modify: 2008-12-19 14:37:32.000000000 +0100
Change: 2009-08-03 15:31:31.000000000 +0200
 Birth: -

So ancient
Comment 36 Fedora End Of Life 2012-08-07 16:09:36 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 37 Miloslav Trmač 2012-08-08 06:40:22 EDT
Reopening based on comment #35 referencing F16.
Comment 38 Michael Cronenworth 2012-08-09 10:58:52 EDT
yn, please do not close this bug. Yes, this is fixed for F17+, but F16 has not been fixed.
Comment 39 Fedora End Of Life 2013-01-16 19:59:19 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 40 Fedora End Of Life 2013-02-13 21:34:25 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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