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. ======================
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.
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.
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
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
I have tried to identify the program on earlier releases, and failed. Let's see if this is happening in F11 as well...
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?
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.....
Yeah, running with just the '-c' option shows the files being deletes.
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
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.
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
Still seeing this at least for /tmp/virtual-*, /tmp/haze-*.
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*
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.
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
(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.
> 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'.
(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.
(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.
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
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.
Still seeing this on F15, e.g. /tmp/virtual-*, /tmp/gnash-cookies.*
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.
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.
(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.
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.
(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.
*** Bug 755681 has been marked as a duplicate of this bug. ***
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.
(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.
(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.
(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?
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
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.
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
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
Reopening based on comment #35 referencing F16.
yn, please do not close this bug. Yes, this is fixed for F17+, but F16 has not been fixed.
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
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.