Why /var/log/tmp looks like this and systemd-private dirs are never automatically deleted, even at reboot?
[root@localhost tmp]# ls -l total 796 drwx------. 2 fxxxxx fxxxxx 4096 Feb 28 13:43 kdecache-fxxxxx drwx------. 2 fxxxxx fxxxxx 4096 Feb 15 14:37 plugtmp-1 -rw-------. 1 akmods akmods 1774 Feb 7 08:54 rpm-tmp.lO73AO drwxrwxrwt. 2 root colord 4096 Feb 5 13:20 systemd-private-0BSkXq drwxrwxrwt. 2 root root 4096 Feb 5 13:20 systemd-private-0r92VC drwxrwxrwt. 2 root root 4096 Feb 6 10:05 systemd-private-18Z8kV drwxrwxrwt. 2 root colord 4096 Feb 28 13:40 systemd-private-1mtzmk drwxrwxrwt. 2 root root 4096 Feb 18 16:04 systemd-private-1om8B3 drwxrwxrwt. 2 root colord 4096 Feb 15 14:41 systemd-private-3SAqrC drwxrwxrwt. 2 root root 4096 Feb 25 14:18 systemd-private-5Q9Qz1 drwxrwxrwt. 2 root root 4096 Feb 15 14:40 systemd-private-6Mg99v drwxrwxrwt. 2 root root 4096 Feb 6 09:52 systemd-private-6QU4nJ drwxrwxrwt. 2 root root 4096 Feb 5 13:16 systemd-private-6YJRWl drwxrwxrwt. 2 root root 4096 Feb 19 19:14 systemd-private-6zp3Cv drwxrwxrwt. 2 root root 4096 Mar 5 10:26 systemd-private-7L4Pjt drwxrwxrwt. 2 root root 4096 Feb 7 08:55 systemd-private-7pmzQ0 drwxrwxrwt. 2 root root 4096 Feb 7 09:14 systemd-private-7soJEi drwxrwxrwt. 2 root root 4096 Feb 18 16:04 systemd-private-7T9Cv4 drwxrwxrwt. 2 root root 4096 Mar 5 10:26 systemd-private-8dDgig drwxrwxrwt. 2 root colord 4096 Feb 7 08:56 systemd-private-8KJQp5 drwxrwxrwt. 2 root root 4096 Feb 17 12:04 systemd-private-8pOtxz drwxrwxrwt. 2 root root 4096 Feb 5 13:19 systemd-private-8VQFuj drwxrwxrwt. 2 root root 4096 Feb 28 13:38 systemd-private-9Di4bj drwxrwxrwt. 2 root root 4096 Feb 22 15:44 systemd-private-acW0io drwxrwxrwt. 2 root root 4096 Mar 4 15:04 systemd-private-Apjy0I drwxrwxrwt. 2 root root 4096 Mar 4 15:04 systemd-private-ArF2aG drwxrwxrwt. 2 root root 4096 Feb 6 10:04 systemd-private-AVF51q drwxrwxrwt. 2 root root 4096 Feb 6 08:39 systemd-private-bq356B drwxrwxrwt. 2 root colord 4096 Feb 25 14:20 systemd-private-BQCmwT drwxrwxrwt. 2 root root 4096 Feb 28 13:39 systemd-private-btdfnp drwxrwxrwt. 2 root colord 4096 Feb 6 08:40 systemd-private-dSAy3j drwxrwxrwt. 2 root root 4096 Feb 20 08:55 systemd-private-dsb6uH drwxrwxrwt. 2 root root 4096 Feb 19 09:51 systemd-private-DvtMAF drwxrwxrwt. 2 root colord 4096 Mar 1 10:55 systemd-private-DXMZSJ drwxrwxrwt. 2 root root 4096 Feb 7 08:56 systemd-private-f0cBSb drwxrwxrwt. 2 root root 4096 Feb 6 10:04 systemd-private-F0ixxU drwxrwxrwt. 2 root root 4096 Mar 4 07:47 systemd-private-f3Xjko drwxrwxrwt. 2 root colord 4096 Feb 6 10:05 systemd-private-f7WM5I drwxrwxrwt. 2 root root 4096 Feb 20 08:56 systemd-private-fhNrpZ drwxrwxrwt. 2 root colord 4096 Feb 22 15:45 systemd-private-Fn8ysU drwxrwxrwt. 2 root root 4096 Feb 15 14:40 systemd-private-fyz8EY drwxrwxrwt. 2 root root 4096 Feb 12 08:42 systemd-private-G5NsRa drwxrwxrwt. 2 root root 4096 Mar 4 07:47 systemd-private-GBa1pl drwxrwxrwt. 2 root colord 4096 Feb 19 09:51 systemd-private-gFN6Ry drwxrwxrwt. 2 root root 4096 Feb 19 10:49 systemd-private-gxR8Ad drwxrwxrwt. 2 root root 4096 Feb 20 08:56 systemd-private-HcqWqN drwxrwxrwt. 2 root colord 4096 Feb 12 08:42 systemd-private-hdD6a1 drwxrwxrwt. 2 root root 4096 Feb 6 08:39 systemd-private-hfjMTZ drwxrwxrwt. 2 root root 4096 Mar 3 03:13 systemd-private-hJfg9v drwxrwxrwt. 2 root root 4096 Mar 4 07:45 systemd-private-HJmYWj drwxrwxrwt. 2 root colord 4096 Mar 5 10:27 systemd-private-i6Kfoy drwxrwxrwt. 2 root root 4096 Feb 28 17:57 systemd-private-iAGwqV drwxrwxrwt. 2 root root 4096 Mar 1 10:54 systemd-private-ikkwgu drwxrwxrwt. 2 root colord 4096 Feb 18 16:26 systemd-private-IOR32Y drwxrwxrwt. 2 root root 4096 Mar 5 10:27 systemd-private-IrN4AE drwxrwxrwt. 2 root root 4096 Mar 4 15:04 systemd-private-IYSOCE drwxrwxrwt. 2 root root 4096 Mar 4 15:05 systemd-private-J7uULn drwxrwxrwt. 2 root root 4096 Feb 12 08:41 systemd-private-jiJcis drwxrwxrwt. 2 root root 4096 Feb 15 14:41 systemd-private-Ka4fXL drwxrwxrwt. 2 root root 4096 Feb 17 12:03 systemd-private-kYwDB2 drwxrwxrwt. 2 root root 4096 Feb 18 16:07 systemd-private-lGkI2t drwxrwxrwt. 2 root root 4096 Feb 17 12:03 systemd-private-ltGenw drwxrwxrwt. 2 root root 4096 Feb 19 09:50 systemd-private-MjSAY2 drwxrwxrwt. 2 root root 4096 Feb 18 16:26 systemd-private-mPQtMX drwxrwxrwt. 2 root root 4096 Feb 18 16:26 systemd-private-Nkuj08 drwxrwxrwt. 2 root colord 4096 Feb 17 12:04 systemd-private-Nmd1Dn drwxrwxrwt. 2 root colord 4096 Feb 28 17:57 systemd-private-NVDF0N drwxrwxrwt. 2 root root 4096 Feb 28 17:56 systemd-private-NvyJtL drwxrwxrwt. 2 root root 4096 Feb 12 08:41 systemd-private-oBhCBm drwxrwxrwt. 2 root root 4096 Feb 7 09:14 systemd-private-OEkHnz drwxrwxrwt. 2 root colord 4096 Feb 6 09:58 systemd-private-oJrcTK drwxrwxrwt. 2 root root 4096 Feb 22 15:44 systemd-private-omYZAn drwxrwxrwt. 2 root root 4096 Feb 6 08:40 systemd-private-plW4hq drwxrwxrwt. 2 root root 4096 Feb 18 16:26 systemd-private-PQk2vt drwxrwxrwt. 2 root root 4096 Feb 7 09:14 systemd-private-PZ28pW drwxrwxrwt. 2 root root 4096 Feb 15 14:40 systemd-private-qzN6zY drwxrwxrwt. 2 root colord 4096 Mar 4 13:42 systemd-private-R2Dco6 drwxrwxrwt. 2 root root 4096 Mar 4 07:47 systemd-private-R4vL5h drwxrwxrwt. 2 root root 4096 Mar 1 10:54 systemd-private-rIFfFj drwxrwxrwt. 2 root root 4096 Feb 28 13:39 systemd-private-rOm7r1 drwxrwxrwt. 2 root root 4096 Feb 6 09:52 systemd-private-RPhMlC drwxrwxrwt. 2 root colord 4096 Mar 4 15:05 systemd-private-sNtDgg drwxrwxrwt. 2 root root 4096 Feb 19 09:50 systemd-private-sQe75z drwxrwxrwt. 2 root root 4096 Feb 28 17:56 systemd-private-TdrkeP drwxrwxrwt. 2 root root 4096 Feb 28 13:39 systemd-private-Twvr7H drwxrwxrwt. 2 root root 4096 Feb 5 13:19 systemd-private-uoB3Sb drwxrwxrwt. 2 root root 4096 Feb 5 13:19 systemd-private-UOkU5V drwxrwxrwt. 2 root root 4096 Feb 18 16:26 systemd-private-Uv3DpE drwxrwxrwt. 2 root root 4096 Feb 6 10:04 systemd-private-v2f36h drwxrwxrwt. 2 root colord 4096 Feb 7 09:14 systemd-private-v376la drwxrwxrwt. 2 root root 4096 Feb 7 08:55 systemd-private-VMX780 drwxrwxrwt. 2 root root 4096 Feb 7 09:14 systemd-private-VuQ0tT drwxrwxrwt. 2 root root 4096 Feb 25 14:20 systemd-private-wG4kk0 drwxrwxrwt. 2 root root 4096 Feb 25 14:18 systemd-private-XfgRge drwxrwxrwt. 2 root root 4096 Feb 22 15:45 systemd-private-XJvd34 drwxrwxrwt. 2 root root 4096 Feb 22 15:44 systemd-private-Xmc9HS drwxrwxrwt. 2 root root 4096 Feb 28 13:40 systemd-private-xPc4Jt drwxrwxrwt. 2 root colord 4096 Feb 20 08:56 systemd-private-y3cD4Q drwxrwxrwt. 2 root root 4096 Feb 12 08:42 systemd-private-YgO6s0 drwxrwxrwt. 2 root root 4096 Mar 4 13:42 systemd-private-YiZCNg drwxrwxrwt. 2 root root 4096 Feb 7 08:55 systemd-private-ySX5m8 drwxrwxrwt. 2 root root 4096 Feb 6 09:58 systemd-private-ySZXzS drwxrwxrwt. 2 root root 4096 Feb 22 15:43 systemd-private-ZKjj2C drwxrwxrwt. 2 root root 4096 Mar 5 10:26 systemd-private-Zmpfjo drwxrwxrwt. 2 root root 4096 Mar 1 10:55 systemd-private-zRNwjK drwxrwxrwt. 2 root root 4096 Feb 6 08:40 systemd-private-zWXX0w -rw-------. 1 fxxxxx fxxxxx 379096 Feb 4 17:11 T8JPgzC0.exe.part [root@localhost tmp]#
C. Sava
On 03/06/13 15:25, Cristian Sava wrote:
Why /var/log/tmp looks like this and systemd-private dirs are never automatically deleted, even at reboot?
[root@localhost tmp]# ls -l total 796 drwx------. 2 fxxxxx fxxxxx 4096 Feb 28 13:43 kdecache-fxxxxx drwx------. 2 fxxxxx fxxxxx 4096 Feb 15 14:37 plugtmp-1 -rw-------. 1 akmods akmods 1774 Feb 7 08:54 rpm-tmp.lO73AO drwxrwxrwt. 2 root colord 4096 Feb 5 13:20 systemd-private-0BSkXq drwxrwxrwt. 2 root root 4096 Feb 5 13:20 systemd-private-0r92VC drwxrwxrwt. 2 root root 4096 Feb 6 10:05 systemd-private-18Z8kV drwxrwxrwt. 2 root colord 4096 Feb 28 13:40 systemd-private-1mtzmk drwxrwxrwt. 2 root root 4096 Feb 18 16:04 systemd-private-1om8B3
This looks fairly normal to me....
You're talking about /var/tmp right? Those files are not cleaned out at boot time but are cleaned out by cron job run on a daily basis.
Look at /etc/cron.daily/tmpwatch. You can modify to change the default from 30d retention to something smaller if you like.
On Wed, 2013-03-06 at 15:47 +0800, Ed Greshko wrote:
On 03/06/13 15:25, Cristian Sava wrote:
Why /var/log/tmp looks like this and systemd-private dirs are never automatically deleted, even at reboot?
[root@localhost tmp]# ls -l total 796 drwx------. 2 fxxxxx fxxxxx 4096 Feb 28 13:43 kdecache-fxxxxx drwx------. 2 fxxxxx fxxxxx 4096 Feb 15 14:37 plugtmp-1 -rw-------. 1 akmods akmods 1774 Feb 7 08:54 rpm-tmp.lO73AO drwxrwxrwt. 2 root colord 4096 Feb 5 13:20 systemd-private-0BSkXq drwxrwxrwt. 2 root root 4096 Feb 5 13:20 systemd-private-0r92VC drwxrwxrwt. 2 root root 4096 Feb 6 10:05 systemd-private-18Z8kV drwxrwxrwt. 2 root colord 4096 Feb 28 13:40 systemd-private-1mtzmk drwxrwxrwt. 2 root root 4096 Feb 18 16:04 systemd-private-1om8B3
This looks fairly normal to me....
You're talking about /var/tmp right? Those files are not cleaned out at boot time but are cleaned out by cron job run on a daily basis.
Look at /etc/cron.daily/tmpwatch. You can modify to change the default from 30d retention to something smaller if you like.
The problem is that they still are there (like here https://bugzilla.redhat.com/show_bug.cgi?id=801943 ) Do you expect any user to delete or fix himself?
C. Sava
On 03/06/13 16:00, Cristian Sava wrote:
The problem is that they still are there (like here https://bugzilla.redhat.com/show_bug.cgi?id=801943 ) Do you expect any user to delete or fix himself?
But, they eventually are deleted.....
[egreshko@meimei ~]$ cd /var/tmp [egreshko@meimei tmp]$ ll total 108 drwx------. 6 egreshko egreshko 4096 Mar 6 16:00 kdecache-egreshko drwx------. 5 1002 1003 4096 Feb 4 13:34 kdecache-myang -rw-------. 1 root root 0 Mar 3 12:13 rpm-tmp.z8N8Rd drwxrwxrwt. 2 root root 4096 Mar 3 13:04 systemd-private-4sS99p drwxrwxrwt. 2 root colord 4096 Feb 27 15:46 systemd-private-6wxbCD drwxrwxrwt. 2 root root 4096 Feb 6 14:32 systemd-private-7jbN09 drwxrwxrwt. 2 root colord 4096 Feb 19 08:27 systemd-private-84gAhC drwxrwxrwt. 2 root colord 4096 Mar 3 12:25 systemd-private-bOnhzu drwxrwxrwt. 2 root root 4096 Feb 17 08:11 systemd-private-dAnZrr drwxrwxrwt. 2 root colord 4096 Feb 6 14:32 systemd-private-E26rBp drwxrwxrwt. 2 root root 4096 Feb 22 09:09 systemd-private-fjvVHl drwxrwxrwt. 2 root root 4096 Feb 22 09:09 systemd-private-ggs9U6 drwxrwxrwt. 2 root root 4096 Feb 27 15:45 systemd-private-GJY00u drwxrwxrwt. 2 root root 4096 Mar 3 12:25 systemd-private-j5GzZq drwxrwxrwt. 2 root root 4096 Feb 9 12:32 systemd-private-leCjUP drwxrwxrwt. 2 root root 4096 Feb 27 15:46 systemd-private-LuXFws drwxrwxrwt. 2 root colord 4096 Mar 3 13:05 systemd-private-ntziW3 drwxrwxrwt. 2 root colord 4096 Feb 17 08:16 systemd-private-NZCEcF drwxrwxrwt. 2 root colord 4096 Feb 9 12:32 systemd-private-oh56H4 drwxrwxrwt. 2 root root 4096 Mar 3 13:05 systemd-private-OKJtxK drwxrwxrwt. 2 root root 4096 Feb 17 08:16 systemd-private-QDKrws drwxrwxrwt. 2 root root 4096 Feb 6 14:31 systemd-private-rV0jnP drwxrwxrwt. 2 root colord 4096 Feb 22 09:09 systemd-private-SIdomt drwxrwxrwt. 2 root root 4096 Feb 19 08:24 systemd-private-sMvNzY drwxrwxrwt. 2 root root 4096 Feb 19 08:27 systemd-private-uhxNFl drwxrwxrwt. 2 root root 4096 Feb 9 12:31 systemd-prvate-vfuPro drwxrwxrwt. 2 root root 4096 Mar 3 12:25 systemd-private-Y0CCdK drwx------. 3 egreshko egreshko 4096 Dec 26 18:52 yum-egreshko-MMIXja
Then I edited /etc/cron.daily/tmpwatch from
/usr/sbin/tmpwatch "$flags" 30d /var/tmp
to
/usr/sbin/tmpwatch "$flags" 5d /var/tmp
Then run the script manually
[egreshko@meimei tmp]$ sudo /etc/cron.daily/tmpwatch [egreshko@meimei tmp]$ ll total 32 drwx------. 4 egreshko egreshko 4096 Mar 6 16:00 kdecache-egreshko -rw-------. 1 root root 0 Mar 3 12:13 rpm-tmp.z8N8Rd drwxrwxrwt. 2 root root 4096 Mar 3 13:04 systemd-private-4sS99p drwxrwxrwt. 2 root colord 4096 Mar 3 12:25 systemd-private-bOnhzu drwxrwxrwt. 2 root root 4096 Mar 3 12:25 systemd-private-j5GzZq drwxrwxrwt. 2 root colord 4096 Mar 3 13:05 systemd-private-ntziW3 drwxrwxrwt. 2 root root 4096 Mar 3 13:05 systemd-private-OKJtxK drwxrwxrwt. 2 root root 4096 Mar 3 12:25 systemd-private-Y0CCdK drwx------. 3 egreshko egreshko 4096 Dec 26 18:52 yum-egreshko-MMIXja
Anything wrong with letting the system clean up its mess like that on a regular basis?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 6 Mar 2013, Ed Greshko wrote:
Anything wrong with letting the system clean up its mess like that on a regular basis?
Yes, is wrong! If any of your services run for more than 5 days, the private tmp directories are removed. Which is wrong!
systemd create systemd-private-XXXXXX directory, is systemd's job to remove-it.
Gabriel
- --
// Gabriel VLASIU // // OpenGPG-KeyID : 44952F15 // OpenGPG-Fingerprint: 4AC5 7C26 2FE9 02DA 4906 24B2 D32B 7ED7 4495 2F15 // OpenGPG-URL : http://www.vlasiu.net/public.key
On 03/06/13 16:17, Gabriel VLASIU wrote:
On Wed, 6 Mar 2013, Ed Greshko wrote:
Anything wrong with letting the system clean up its mess like that on a regular basis?
Yes, is wrong! If any of your services run for more than 5 days, the private tmp directories are removed. Which is wrong!
systemd create systemd-private-XXXXXX directory, is systemd's job to remove-it.
So you feel the -u parameter (access time) isn't sufficient to keep from deleting directories in use?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 6 Mar 2013, Ed Greshko wrote:
So you feel the -u parameter (access time) isn't sufficient to keep from deleting directories in use?
If the service did not access the private tmp directory in X day, yes.
https://bugzilla.redhat.com/show_bug.cgi?id=801943
Gabriel
- --
// Gabriel VLASIU // // OpenGPG-KeyID : 44952F15 // OpenGPG-Fingerprint: 4AC5 7C26 2FE9 02DA 4906 24B2 D32B 7ED7 4495 2F15 // OpenGPG-URL : http://www.vlasiu.net/public.key
On 03/06/13 16:52, Gabriel VLASIU wrote:
On Wed, 6 Mar 2013, Ed Greshko wrote:
So you feel the -u parameter (access time) isn't sufficient to keep from deleting directories in use?
If the service did not access the private tmp directory in X day, yes.
I see nothing in that bugzilla which states that a service has failed due to a directory in /var/tmp/systemd-private-* being deleted by the cron job while the file/directory was in use.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 6 Mar 2013, Ed Greshko wrote:
I see nothing in that bugzilla which states that a service has failed due to a directory in /var/tmp/systemd-private-* being deleted by the cron job while the file/directory was in use.
I did not say that.
The bug has the title: "remove empty private tmp directories after use". Again, is systemd's job to remove them since systemd created those directories in the first place!
1. Create the private directory 2. Start the service 3. Stop the service (or the service somehow die) 4. Remove the directory created in step 1 (clean-up).
And how do you know that all services in fedora continue to work fine if the private tmp is deleted? Did you us strace on all of them? :-)
tmpwatch is kid of evil (from my point of view). It's fine on a laptop which is restarted every day. Not so fine on a server.
Just my 2 cents point of view.
Gabriel
- --
// Gabriel VLASIU // // OpenGPG-KeyID : 44952F15 // OpenGPG-Fingerprint: 4AC5 7C26 2FE9 02DA 4906 24B2 D32B 7ED7 4495 2F15 // OpenGPG-URL : http://www.vlasiu.net/public.key
Am 06.03.2013 10:03, schrieb Ed Greshko:
On 03/06/13 16:52, Gabriel VLASIU wrote:
On Wed, 6 Mar 2013, Ed Greshko wrote:
So you feel the -u parameter (access time) isn't sufficient to keep from deleting directories in use?
If the service did not access the private tmp directory in X day, yes.
I see nothing in that bugzilla which states that a service has failed due to a directory in /var/tmp/systemd-private-* being deleted by the cron job while the file/directory was in use.
and THAT it what happens!
if nothing is using the PrivateTmp which reflects /tmp for the service all is fine and you would not need it at all, if the service is using it you are f**ed
-------- Original-Nachricht -------- Betreff: [systemd-devel] PrivateTmp and "tmpwatch" Datum: Sun, 03 Feb 2013 16:52:42 +0100 Von: Reindl Harald h.reindl@thelounge.net Organisation: the lounge interactive design An: Mailing-List systemd systemd-devel@lists.freedesktop.org
hi
may it be that PrivateTmp does not refresh the folders /tmp/systemd-private* and if "tmpwatch" is deleting them they are mnot re-created?
Can't create/write to file '/tmp/#sql_57d8_0.MYI' (Errcode: 2)
after restart mysqld.service which is here configured with PrivateTmp all is fine again - recently i decided to dedicate a special folder for mysqltmp and modified my daily logwatch to ignore folders starting with "systemd-" but this is not really perfect
i would suggest systemd to touch the folders regulary or watch if they are removed by whatever foreign process and re-create them
[root@buildserver:~]$ rpm -q systemd systemd-44-23.fc17.x86_64
On 03/06/13 17:20, Reindl Harald wrote:
Am 06.03.2013 10:03, schrieb Ed Greshko:
On 03/06/13 16:52, Gabriel VLASIU wrote:
On Wed, 6 Mar 2013, Ed Greshko wrote:
So you feel the -u parameter (access time) isn't sufficient to keep from deleting directories in use?
If the service did not access the private tmp directory in X day, yes.
I see nothing in that bugzilla which states that a service has failed due to a directory in /var/tmp/systemd-private-* being deleted by the cron job while the file/directory was in use.
and THAT it what happens!
if nothing is using the PrivateTmp which reflects /tmp for the service all is fine and you would not need it at all, if the service is using it you are f**ed
Shouldn't the -umc flag of tmpwatch prevent directories in use from being deleted?
If you know of a service which doesn't access its related /var/tmp/systemd-private-* in 30 days and then subsequently fails when deleted by the tmpwatch cron job then please bugzilla it.
Am 06.03.2013 10:31, schrieb Ed Greshko:
On 03/06/13 17:20, Reindl Harald wrote:
Am 06.03.2013 10:03, schrieb Ed Greshko:
On 03/06/13 16:52, Gabriel VLASIU wrote:
On Wed, 6 Mar 2013, Ed Greshko wrote:
So you feel the -u parameter (access time) isn't sufficient to keep from deleting directories in use?
If the service did not access the private tmp directory in X day, yes.
I see nothing in that bugzilla which states that a service has failed due to a directory in /var/tmp/systemd-private-* being deleted by the cron job while the file/directory was in use.
and THAT it what happens!
if nothing is using the PrivateTmp which reflects /tmp for the service all is fine and you would not need it at all, if the service is using it you are f**ed
Shouldn't the -umc flag of tmpwatch prevent directories in use from being deleted?
define in use
it is not in use all the time until the service creates a temp-file and if this is a long time after service start it fails - not more and not less
If you know of a service which doesn't access its related /var/tmp/systemd-private-* in 30 days and then subsequently fails when deleted by the tmpwatch cron job then please bugzilla it.
tmpwatch is broken by design
On Wed, 06 Mar 2013 10:00:05 +0200 Cristian Sava csava@central.ucv.ro wrote:
The problem is that they still are there (like here https://bugzilla.redhat.com/show_bug.cgi?id=801943 ) Do you expect any user to delete or fix himself?
C. Sava
If you don't want to wait for the system to clean itself. or modify as per Ed suggestion. try "yum info bleachbit"
On Wed, 2013-03-06 at 15:47 +0800, Ed Greshko wrote:
On 03/06/13 15:25, Cristian Sava wrote:
Why /var/log/tmp looks like this and systemd-private dirs are never automatically deleted, even at reboot?
[root@localhost tmp]# ls -l total 796 drwx------. 2 fxxxxx fxxxxx 4096 Feb 28 13:43 kdecache-fxxxxx drwx------. 2 fxxxxx fxxxxx 4096 Feb 15 14:37 plugtmp-1 -rw-------. 1 akmods akmods 1774 Feb 7 08:54 rpm-tmp.lO73AO drwxrwxrwt. 2 root colord 4096 Feb 5 13:20 systemd-private-0BSkXq drwxrwxrwt. 2 root root 4096 Feb 5 13:20 systemd-private-0r92VC drwxrwxrwt. 2 root root 4096 Feb 6 10:05 systemd-private-18Z8kV drwxrwxrwt. 2 root colord 4096 Feb 28 13:40 systemd-private-1mtzmk drwxrwxrwt. 2 root root 4096 Feb 18 16:04 systemd-private-1om8B3
This looks fairly normal to me....
You're talking about /var/tmp right? Those files are not cleaned out at boot time but are cleaned out by cron job run on a daily basis.
Look at /etc/cron.daily/tmpwatch. You can modify to change the default from 30d retention to something smaller if you like.
--
From now on, at least during winter time, Im going to blame all spelling an grammar erros on the cat sitting on my chest every time I sit down at the computer....
Sorry, you're right. February has 28 days. C.Sava
-
Cristian Sava -
Ed Greshko -
Frank Murphy -
Gabriel VLASIU -
Reindl Harald