F18 - systemd question

[Cristian Sava]

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

[Gabriel VLASIU]

-----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


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
>
> iQIcBAEBCgAGBQJRNwlKAAoJENMrftdElS8Vi4IP/ipUEqLMSTb/0sonuL0whg8N
> dLLcpM5itWJiXKJY1KFsSdM0ccjA25VKBV6J5Bh05kGoIl/fVbtcWMICBv48KlCX
> zRXhbj4R+v6SERIyuTxgTiSqeLU3/4sIH732CR7fyvKLe3hvl2y4nwGytohFHqy2
> +BwWdjOMjBMqyllBztv2YnBIuYWc/ED4ZTeM14PkmRfFLYvyQ5wEoRVd2hjpcw/h
> ahbKbvw3NFsXrO6IlquqQK6llq4vg0MP+0dchz1ryH4BJdSTwMgEC+v7gGE3kQuk
> laLrAJhGd9EPUikGhBN5kie1YMNWH6hf54TG51pLBEeXmNaSy9+3RIgDZxVbeTEj
> JpRyijBSyD7wFbGnWH+JC5H21dTT1THeON65tiiwZs3ZZEpoQjEph4Ae71yxK5TW
> Dy7l2GGyahkjF0xcrIKfH4ynzvMmDggCR0atsmnmW00KOIiW7Iq90aVwKbQ4kXcn
> AW4yp4pMqSiSRzOBo8kLEVU1L330O2q1TRPDavquH7XfRklzSrvzBzllHmZk6yWv
> l7O6gNqNgZnhGfldWuLflNNNWIDgHkLcu8cNPGfm8sKNnaQa9HhXgkce2ExZaNkc
> IR/ni0EV8p4xrQP7MzYbAicXrZMduRkFeiB4G6vw8t9R9gC1SAbRWPTAS19j8Qf2
> LdWpIjmg3WJ9IcKhFigL
> =XOYV
> -----END PGP SIGNATURE-----

[Frank Murphy]

On Wed, 06 Mar 2013 10:00:05 +0200
Cristian Sava <csava(a)central.ucv.ro&gt; 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"


-- 
Regards,
Frank
http//www.frankly3d.com

[Reindl Harald]

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.
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=801943
> >>>
> >> 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

[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.
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=801943
> >>
> > 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.





-- 
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....

[Reindl Harald]

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.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=801943
> > 
>  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(a)thelounge.net&gt;
Organisation: the lounge interactive design
An: Mailing-List systemd <systemd-devel(a)lists.freedesktop.org&gt;

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

[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.
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=801943
>
>  
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. 


-- 
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....

[Gabriel VLASIU]

-----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


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
>
> iQIcBAEBCgAGBQJRNwO4AAoJENMrftdElS8VZGkP/13o3+Xa+sGnIq/P7URWKuvn
> 0YwM+RY0MX8/RAe7KGXVQBwAKWUF45iG6qcMCtOFUFuiGj0LaCk0FQeVa5bZ5iUR
> b2AS6gBLSudOqW2UbhckEV3KxBnwKLZrInpoXxgbTgnGLJ8XttUpC3AaJ9jPBGnB
> 3Ke//ilr0eMuHN6jji4V/hvePQwdaVLeR7blwUuQCBJezC2ZkwQmreddWlNZMd4j
> qNLbuReXnC1gYvFVoDXPMN2dE/gnKm0jg92E13R4lvv0WPJiIjEW5NT5T40KhhIo
> Z/4ORaAV2WlVwbXX4ynE3Yw6bNnrkVqDYBaKt8w0xHFNzJtC5ASJ3edbAVBC8mia
> IE9rHg7uMxEhmHQstFZ1nylRZFEag1f4ni6TL/6Ce+OEN6gkdWdZjZEToalv/n9X
> mGrbk8RTb2sWUbTBAyU4rI8Mm2aXByu10jMWnGUlV22rfQsGYwIIDu99Y84FOJyY
> 8WnONJKo0OEDQifxWN0cvuutw1E4cXKPcYzt82MaKdeQI07JWO4tc7ny9oTDa3IR
> psuKY4JznTNjThXZR7hf8TR6LL0dKlwdVJYibo6fPu++OLg1nHlSt0bBVpYt98o4
> /s91+faDlflZ792gStiO1Sq74LoqkhKiT/t+YAUWfDc2xRYIRLwVPaR0ahVi7ZaV
> nkxjdRNll8eOVS50BYHd
> =ZJit
> -----END PGP SIGNATURE-----

[Ed Greshko]

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?  

-- 
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....

[Gabriel VLASIU]

-----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


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
>
> iQIcBAEBCgAGBQJRNvu2AAoJENMrftdElS8VQ5YP/A2NKhYlRoFVhaC8gHgZT/kE
> rtYzTvBNlRJX5KyZ4+UQ7JrNnD8lIqScHWa9t+IILwImxqkVqj8J8Mu82rdPDguZ
> WN7eHIMszBgy2A+uIvfHi6ekfxafw5ELAG6ccQKgw7USdWVsrSqdiZGgjQN09S+z
> 7ZMGQk8XV+TpNszJ8GL0fEDVue/oboFM5MxltG2CWrg22kgBUAsjVKWbBUvUcLmM
> j2GJqwzKVa1hFE8/ep3/v8bkgUTO6qa4J335JDy9v7iso/sLP7yagTk/cJ7V3RMn
> M7WaqPkvMVcv0Kl8RZhI7h7nCfoOltqV4etwKnba24BqpilWtAtVKnJnNrR0eUwJ
> tMZjeloXN6LV9hlXLW8q/u7ztq68nRDF8MjKzME8+SiO9JLinUpE5yM5dpBNh/4Y
> B7qkH6gbjfYX9gH7OGqblSvRkrcVE3F5g0XL9N2L3lVPL2onPpe4Ah5Y2tm69hNp
> kHnYMEHJYI4sCoBpcH8uAGwGx9aF6KpO5Pr7ZCxTEusBDmrG+aGCXN//cjrf9fD4
> +qj686MdzW1Z7yA1NmffjDjlQFk1aK0H3KDTNk81HdLfwHCcIjq8yU5h93WEv4nG
> aOpjmSPGFXbfOWP+ozJxPVVvqhStq6pMqpxfjARVKFkSNX5cI423BaXgjZKxlWW8
> ntDcoCdfD53lzHWyOM7f
> =5nAa
> -----END PGP SIGNATURE-----

[Cristian Sava]

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

[Ed Greshko]

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?

-- 
> 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....

[Cristian Sava]

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

[Ed Greshko]

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....