Several systemd-private-* directories in /tmp

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Several systemd-private-* directories in /tmp

Andrea Turrini
Hi all,

after having installed oS 12.3 from scratch two weeks ago, I have found
that /tmp contains a lot of systemd-private-* directories. Currently
there are 85 of such directories but hopefully they are all empty, so
they do not waste too much space.

Is it correct that such directories remain in /tmp? Why are they not
removed by systemd on shutdown?

Best,
Andrea
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Anton Aylward-2
Andrea Turrini said the following on 05/05/2013 08:06 AM:
> Hi all,
>
> after having installed oS 12.3 from scratch two weeks ago, I have found
> that /tmp contains a lot of systemd-private-* directories. Currently
> there are 85 of such directories but hopefully they are all empty, so
> they do not waste too much space.
>
> Is it correct that such directories remain in /tmp? Why are they not
> removed by systemd on shutdown?

I can't imagine why they are there in the first place.

Its not the job of systemd to purge /tmp.
That's done by a cron job.  We've discussed that issue here recently.
Take a look at /etc/cron.daily/suse.de-clean-tmp
and at /etc/sysconfig/cron

--
"A PICTURE IS WORTH A THOUSAND WORDS--But it uses up a thousand times
the memory."
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Carlos E. R.-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Sunday, 2013-05-05 at 08:42 -0400, Anton Aylward wrote:

> Andrea Turrini said the following on 05/05/2013 08:06 AM:
>> Hi all,
>>
>> after having installed oS 12.3 from scratch two weeks ago, I have found
>> that /tmp contains a lot of systemd-private-* directories. Currently
>> there are 85 of such directories but hopefully they are all empty, so
>> they do not waste too much space.
>>
>> Is it correct that such directories remain in /tmp? Why are they not
>> removed by systemd on shutdown?
>
> I can't imagine why they are there in the first place.
I have them too, I just looked.
It is a fresh 12.3 system installed under vmware player.


> Its not the job of systemd to purge /tmp.
> That's done by a cron job.  We've discussed that issue here recently.

Of course it is the job of systemd! Any program creating temporary files
should destroy them when they finish. Having a cronjob deleting them is a
hack for careless programming.

> Take a look at /etc/cron.daily/suse.de-clean-tmp
> and at /etc/sysconfig/cron


That is deprecated and does not work. It doesn't, because those files are
owned by root. And it doesn't because if systemd is running the cron job
does not work. See release notes:


+++···································
5.2. systemd: Cleaning Directories (/tmp and /var/tmp)

By default, systemd cleans tmp directories daily as configured in
/usr/lib/tmpfiles.d/tmp.conf. Users can change it by copying
/usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/tmp.conf and modifying the
copied file. It will override /usr/lib/tmpfiles.d/tmp.conf.

Note: systemd does not honor obsolete sysconfig variables in
/etc/sysconfig/cron such as TMP_DIRS_TO_CLEAR.
···································++-


- --
Cheers,
        Carlos E. R.
        (from 12.1 x86_64 "Asparagus" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlGGWKIACgkQtTMYHG2NR9WqTQCfYnvafSJmAfdcZG56IQrQ9WpY
v/UAmwQDOpd6haPrdE36D9SQ8vbxB0pO
=4Uv9
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

bruce
在 2013年5月5日 星期日 15:03:22,Carlos E. R. 写道:
> > Its not the job of systemd to purge /tmp.
> > That's done by a cron job.  We've discussed that issue here recently.
>
> Of course it is the job of systemd! Any program creating temporary files
> should destroy them when they finish. Having a cronjob deleting them is a
> hack for careless programming.
>
i agree. who created these temporary files , should delete these files. its
their responsibility.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Anton Aylward-2
In reply to this post by Carlos E. R.-2
Carlos E. R. said the following on 05/05/2013 09:03 AM:
>> > Take a look at /etc/cron.daily/suse.de-clean-tmp
>> > and at /etc/sysconfig/cron
>
> That is deprecated and does not work. It doesn't, because those files are
> owned by root. And it doesn't because if systemd is running the cron job
> does not work. See release notes:

My Bad.  Thank you for the correction.
I looked on my 12.2 system rather than 12.3.
I see that /etc/cron.daily/suse.de-clean-tmp isn't there on my 12.3 system.

Sadly /etc/sysconfig/cron is.
Hmm, that was a clean install on the 12.3 machine I'm looking at so I
can't blame it on being a residue of an update.

That still doesn't answer why they got created and left behind in the
first place.  You point out that programs _should_ clean up after
themselves, but I've never relied on that.  "Evidence".

Systemd is "ongoing" and there still a lot to learn.


--
Doubt is not a pleasant condition, but certainty is absurd.
  -- Voltaire
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Andrea Turrini
In reply to this post by Carlos E. R.-2
On 05/05/2013 03:03 PM, Carlos E. R. wrote:
>
>
> On Sunday, 2013-05-05 at 08:42 -0400, Anton Aylward wrote:
>>> Is it correct that such directories remain in /tmp? Why are they not
>>> removed by systemd on shutdown?
>
>> I can't imagine why they are there in the first place.

I have no idea, that's why I asked.

>> Its not the job of systemd to purge /tmp.
>> That's done by a cron job.  We've discussed that issue here recently.
>
> Of course it is the job of systemd! Any program creating temporary files
> should destroy them when they finish. Having a cronjob deleting them is
> a hack for careless programming.

This is what I have understood from such discussion, but probably I am
wrong.

>> Take a look at /etc/cron.daily/suse.de-clean-tmp

I would like, but

ls: cannot access /etc/cron.daily/suse.de-clean-tmp: No such file or
directory

In oS 12.2 such file was provided by aaa_base, but in oS 12.3 this file
is missing (also yast2 sw_single does not show any package when
searching for suse.de-clean-tmp).

>> and at /etc/sysconfig/cron
>
>
> That is deprecated and does not work. It doesn't, because those files
> are owned by root. And it doesn't because if systemd is running the cron
> job does not work. See release notes:
>
>
> +++···································
> 5.2. systemd: Cleaning Directories (/tmp and /var/tmp)
>
> By default, systemd cleans tmp directories daily as configured in
> /usr/lib/tmpfiles.d/tmp.conf. Users can change it by copying
> /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/tmp.conf and modifying
> the copied file. It will override /usr/lib/tmpfiles.d/tmp.conf.
>
> Note: systemd does not honor obsolete sysconfig variables in
> /etc/sysconfig/cron such as TMP_DIRS_TO_CLEAR.
> ···································++-

BTW, my non-comment part of /etc/sysconfig/cron as from installation is:

MAX_DAYS_IN_TMP="0"
MAX_DAYS_IN_LONG_TMP="0"
TMP_DIRS_TO_CLEAR=""
LONG_TMP_DIRS_TO_CLEAR=""
OWNER_TO_KEEP_IN_TMP="root"
CLEAR_TMP_DIRS_AT_BOOTUP=""
DAILY_TIME=""
MAX_NOT_RUN="5"
SEND_MAIL_ON_NO_ERROR="no"
SEND_OUTPUT_ON_NO_ERROR="no"
SYSLOG_ON_NO_ERROR="no"
REINIT_MANDB=yes
DELETE_OLD_CATMAN=yes
CATMAN_ATIME=7


Now, I have checked the content of /usr/lib/tmpfiles.d/tmp.conf and I am
quite surprise that these systemd-private-* directories are kept by
choice, and they are also replicated in /var/tmp (with different suffixes):

# Exclude namespace mountpoints created with PrivateTmp=yes
X /tmp/systemd-private-*
X /var/tmp/systemd-private-*

So, does this mean that these directories will eventually saturate my /
partition? And is it safe to manually remove them?

Best,
Andrea
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Marcus Meissner
In reply to this post by Anton Aylward-2
On Sun, May 05, 2013 at 09:28:41AM -0400, Anton Aylward wrote:

> Carlos E. R. said the following on 05/05/2013 09:03 AM:
> >> > Take a look at /etc/cron.daily/suse.de-clean-tmp
> >> > and at /etc/sysconfig/cron
> >
> > That is deprecated and does not work. It doesn't, because those files are
> > owned by root. And it doesn't because if systemd is running the cron job
> > does not work. See release notes:
>
> My Bad.  Thank you for the correction.
> I looked on my 12.2 system rather than 12.3.
> I see that /etc/cron.daily/suse.de-clean-tmp isn't there on my 12.3 system.
>
> Sadly /etc/sysconfig/cron is.
> Hmm, that was a clean install on the 12.3 machine I'm looking at so I
> can't blame it on being a residue of an update.
>
> That still doesn't answer why they got created and left behind in the
> first place.  You point out that programs _should_ clean up after
> themselves, but I've never relied on that.  "Evidence".

I suspect this is the "PrivateTmp=true" feature of systemd, where
systemservices get their own /tmp to avoid generic tmp race attacks.

So basically a security feature.

No idea about how the clean up works there, if it does not, report
a bug I would say :/

> Systemd is "ongoing" and there still a lot to learn.

Ciao, Marcus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Carlos E. R.-2
In reply to this post by Anton Aylward-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Sunday, 2013-05-05 at 09:28 -0400, Anton Aylward wrote:

> Carlos E. R. said the following on 05/05/2013 09:03 AM:
>>>> Take a look at /etc/cron.daily/suse.de-clean-tmp
>>>> and at /etc/sysconfig/cron
>>
>> That is deprecated and does not work. It doesn't, because those files are
>> owned by root. And it doesn't because if systemd is running the cron job
>> does not work. See release notes:
>
> My Bad.  Thank you for the correction.
> I looked on my 12.2 system rather than 12.3.
> I see that /etc/cron.daily/suse.de-clean-tmp isn't there on my 12.3 system.
>
> Sadly /etc/sysconfig/cron is.
> Hmm, that was a clean install on the 12.3 machine I'm looking at so I
> can't blame it on being a residue of an update.

No, I see the same thing in my fresh 12.3 test system.
"/etc/sysconfig/cron" is there, populated, and there is no mention that
the part about cleaning /tmp does not work any more. Another bug.


> That still doesn't answer why they got created and left behind in the
> first place.  You point out that programs _should_ clean up after
> themselves, but I've never relied on that.  "Evidence".

I know, I know. Still, the fault is with the programs creating the cruft,
not of those clearing out after them.


> Systemd is "ongoing" and there still a lot to learn.

Yes... :-(


Aparently, the clearing is done by "/usr/lib/tmpfiles.d/tmp.conf":

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published
by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

# Clear tmp directories separately, to make them easier to override
d /tmp 1777 root root 10d
d /var/tmp 1777 root root 30d

# Exclude namespace mountpoints created with PrivateTmp=yes
X /tmp/systemd-private-*
X /var/tmp/systemd-private-*


So those files are intentionally not erased.


- --
Cheers,
        Carlos E. R.
        (from 12.1 x86_64 "Asparagus" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlGGZLUACgkQtTMYHG2NR9VAkQCfXtBlMQeKYotDlE2WRrQPrNCu
tVkAn0DTD1O/r9vUp+tbCpM2Trys5lcC
=uk3/
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Carlos E. R.-2
In reply to this post by Marcus Meissner
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Sunday, 2013-05-05 at 15:39 +0200, Marcus Meissner wrote:

> No idea about how the clean up works there, if it does not, report
> a bug I would say :/

It will probably be ignored, or wontfixed, or invalid, or whatever, as
those files are intentionally not erased:

# Exclude namespace mountpoints created with PrivateTmp=yes
X /tmp/systemd-private-*
X /var/tmp/systemd-private-*


- --
Cheers,
        Carlos E. R.
        (from 12.1 x86_64 "Asparagus" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlGGZUsACgkQtTMYHG2NR9UIdgCglOzEjV8xd6JS1I6ujhqPzqw9
zA8An1suTE+frR5+iCedqXcxg/nJj5ND
=IGnV
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Rüdiger Meier
On Sunday 05 May 2013, Carlos E. R. wrote:

> On Sunday, 2013-05-05 at 15:39 +0200, Marcus Meissner wrote:
> > No idea about how the clean up works there, if it does not, report
> > a bug I would say :/
>
> It will probably be ignored, or wontfixed, or invalid, or whatever,
> as those files are intentionally not erased:
>
> # Exclude namespace mountpoints created with PrivateTmp=yes
> X /tmp/systemd-private-*
> X /var/tmp/systemd-private-*

I assume they shall not be removed during uptime but at least on reboot.
The fact that they are "still" there after reboot could be because they
are simply re-created.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Carlos E. R.-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Sunday, 2013-05-05 at 16:11 +0200, Ruediger Meier wrote:

> On Sunday 05 May 2013, Carlos E. R. wrote:
>
> I assume they shall not be removed during uptime but at least on reboot.
> The fact that they are "still" there after reboot could be because they
> are simply re-created.

Nope, the dates do not match:


eleanor3:~ # uptime
  16:12  up  21:25,  6 users,  load average: 0,00, 0,01, 0,05

eleanor3:~ # l /tmp/systemd-private-*
/tmp/systemd-private-FawLUZ:
total 8
drwxrwxrwt  2 root root 4096 May  1 04:32 ./
drwxrwxrwt 17 root root 4096 May  5 16:00 ../

/tmp/systemd-private-GLcQqj:
total 8
drwxrwxrwt  2 root root 4096 May  1 03:30 ./
drwxrwxrwt 17 root root 4096 May  5 16:00 ../

/tmp/systemd-private-Wpa6pD:
total 8
drwxrwxrwt  2 root root 4096 May  2 05:07 ./
drwxrwxrwt 17 root root 4096 May  5 16:00 ../

/tmp/systemd-private-h6yFZV:
total 8
drwxrwxrwt  2 root root 4096 May  1 02:54 ./
drwxrwxrwt 17 root root 4096 May  5 16:00 ../

/tmp/systemd-private-jQoKLO:
total 8
drwxrwxrwt  2 root root 4096 May  2 11:14 ./
drwxrwxrwt 17 root root 4096 May  5 16:00 ../
eleanor3:~ #


They are directories older than my reboot, and they are random names. If
they are recreated, they should get a new name and a different, current,
date - which is what happens, and the old one remains.


eleanor3:~ # lsof | grep systemd-private
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
       Output information may be incomplete.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /var/run/user/1000/gvfs
       Output information may be incomplete.
eleanor3:~ #

- --
Cheers,
        Carlos E. R.
        (from 12.1 x86_64 "Asparagus" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlGGalAACgkQtTMYHG2NR9VTsACdETv6tAPy+PB0P0ve4R6Mz4Ss
f0EAoIiiqWyj+m473tqaRA4RMBU28fKM
=19KQ
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Anton Aylward-2
In reply to this post by Andrea Turrini
Andrea Turrini said the following on 05/05/2013 09:29 AM:

> Now, I have checked the content of /usr/lib/tmpfiles.d/tmp.conf and I am
> quite surprise that these systemd-private-* directories are kept by
> choice, and they are also replicated in /var/tmp (with different suffixes):
>
> # Exclude namespace mountpoints created with PrivateTmp=yes
> X /tmp/systemd-private-*
> X /var/tmp/systemd-private-*
>
> So, does this mean that these directories will eventually saturate my /
> partition? And is it safe to manually remove them?

Good heavens!
I just looked at my 12.3 box and they are there, just as you say.

The note about "namespace mountpoints created with PrivateTmp=yes"
temms me a lot.  Now I egrep for "PrivateTmp=yes"

# grep -R "PrivateTmp=yes" /etc /lib /usr/lib
/etc/systemd/system/multi-user.target.wants/haveged.service:PrivateTmp=yes
/usr/lib/systemd/system/haveged.service:PrivateTmp=yes

Hmm.  Hardly seems enough to create all those tmpfiles.
Oh, right, one e set each time I book and them again later in the day
for some reason.

But why aren't they being cleared away?

--
Psst! Viral marketing works! Tell everyone you know!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Andrea Turrini
In reply to this post by Rüdiger Meier
On 05/05/2013 04:11 PM, Ruediger Meier wrote:

> On Sunday 05 May 2013, Carlos E. R. wrote:
>> On Sunday, 2013-05-05 at 15:39 +0200, Marcus Meissner wrote:
>>> No idea about how the clean up works there, if it does not, report
>>> a bug I would say :/
>>
>> It will probably be ignored, or wontfixed, or invalid, or whatever,
>> as those files are intentionally not erased:
>>
>> # Exclude namespace mountpoints created with PrivateTmp=yes
>> X /tmp/systemd-private-*
>> X /var/tmp/systemd-private-*
>
> I assume they shall not be removed during uptime but at least on reboot.
> The fact that they are "still" there after reboot could be because they
> are simply re-created.

As far I can say, they are not removed but still created on boot, but
only a couple of directory for each boot. For example:
drwxrwxrwt   2 root root   4096 Apr 29 07:54 systemd-private-2yyLEI
drwxrwxrwt   2 root root   4096 Apr 29 07:54 systemd-private-Gzd0XH
drwxrwxrwt   2 root root   4096 May  4 08:41 systemd-private-agaLq4
drwxrwxrwt   2 root root   4096 May  4 08:42 systemd-private-qVMGoh
drwxrwxrwt   2 root root   4096 May  5 08:20 systemd-private-jIrpAY
drwxrwxrwt   2 root root   4096 May  5 08:22 systemd-private-TdeEvw

I have them from Apr 21 till today, except for May 1 where the usual two
directories are not there, even if I am sure that I have booted the system.

The same happens in /var/tmp.

Best,
Andrea
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Andrei Borzenkov
In reply to this post by Marcus Meissner
В Sun, 5 May 2013 15:39:59 +0200
Marcus Meissner <[hidden email]> пишет:

> On Sun, May 05, 2013 at 09:28:41AM -0400, Anton Aylward wrote:
> > Carlos E. R. said the following on 05/05/2013 09:03 AM:
> > >> > Take a look at /etc/cron.daily/suse.de-clean-tmp
> > >> > and at /etc/sysconfig/cron
> > >
> > > That is deprecated and does not work. It doesn't, because those files are
> > > owned by root. And it doesn't because if systemd is running the cron job
> > > does not work. See release notes:
> >
> > My Bad.  Thank you for the correction.
> > I looked on my 12.2 system rather than 12.3.
> > I see that /etc/cron.daily/suse.de-clean-tmp isn't there on my 12.3 system.
> >
> > Sadly /etc/sysconfig/cron is.
> > Hmm, that was a clean install on the 12.3 machine I'm looking at so I
> > can't blame it on being a residue of an update.
> >
> > That still doesn't answer why they got created and left behind in the
> > first place.  You point out that programs _should_ clean up after
> > themselves, but I've never relied on that.  "Evidence".
>
> I suspect this is the "PrivateTmp=true" feature of systemd, where
> systemservices get their own /tmp to avoid generic tmp race attacks.
>
> So basically a security feature.
>
> No idea about how the clean up works there, if it does not, report
> a bug I would say :/
>

Unfortunately in version we have these directories were created far too
late to remove them in place (they were created in child right before
exec so there was no code to remove them) and removing them during
periodic cleanup is probably wrong as well (they may belong to long
running service processes).

In current upstream they are created differently and cleaned up when
service stops.

There is still corner case when system crashes and leaves those
directories behind. So I think we still need to at least clean them up
on reboot.

bor@opensuse:~> cat /etc/tmpfiles.d/remove-systemd-private.conf
R /tmp/systemd-private-*
R /var/tmp/systemd-private-*
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

James Knott
In reply to this post by Andrea Turrini
Andrea Turrini wrote:
> As far I can say, they are not removed but still created on boot, but
> only a couple of directory for each boot. For example:

I just checked my computer and here's what I found:

drwxrwxrwt 2 root   root  4096 Apr 24 12:09 systemd-private-2gKZyv
drwxrwxrwt 2 root   root  4096 Apr 24 21:25 systemd-private-6MFjVn
drwxrwxrwt 2 root   root  4096 May  4 17:24 systemd-private-8zo3Eo
drwxrwxrwt 2 root   root  4096 Mar 17 14:59 systemd-private-bVGstg
drwxrwxrwt 2 root   root  4096 Apr 24 21:24 systemd-private-BXDnMv
drwxrwxrwt 2 root   root  4096 Mar 17 16:00 systemd-private-C237qO
drwxrwxrwt 2 root   root  4096 Mar 17 12:01 systemd-private-cEyZ05
drwxrwxrwt 2 root   root  4096 Apr 24 11:01 systemd-private-dmmo9K
drwxrwxrwt 2 root   root  4096 Apr 24 21:27 systemd-private-EEnv1Z
drwxrwxrwt 2 root   root  4096 Apr 24 09:59 systemd-private-Ek4LCl
drwxrwxrwt 2 root   root  4096 Mar 17 15:09 systemd-private-Fc4HJs
drwxrwxrwt 2 root   root  4096 Apr 24 12:11 systemd-private-FtjArW
drwxrwxrwt 2 root   root  4096 Apr 23 22:14 systemd-private-HCIkny
drwxrwxrwt 2 root   root  4096 Apr 25 19:06 systemd-private-hosYEx
drwxrwxrwt 2 root   root  4096 Apr 24 10:00 systemd-private-JOJgHa
drwxrwxrwt 2 root   root  4096 Apr 24 12:09 systemd-private-jRJ340
drwxrwxrwt 2 root   root  4096 Mar 17 22:17 systemd-private-JUoAXO
drwxrwxrwt 2 root   root  4096 Apr 17 22:16 systemd-private-mJKLM7
drwxrwxrwt 2 root   root  4096 Apr 17 22:17 systemd-private-Myq6HP
drwxrwxrwt 2 root   root  4096 Mar 17 11:56 systemd-private-niTHSX
drwxrwxrwt 2 root   root  4096 Apr 24 11:00 systemd-private-Nw85Ea
drwxrwxrwt 2 root   root  4096 Apr 23 22:15 systemd-private-OQy485
drwxrwxrwt 2 root   root  4096 May  4 17:41 systemd-private-OUeOXm
drwxrwxrwt 2 root   root  4096 Mar 17 22:16 systemd-private-OwbrW2
drwxrwxrwt 2 root   root  4096 Apr 25 19:07 systemd-private-TOV1Bc
drwxrwxrwt 2 root   root  4096 Apr 24 21:28 systemd-private-UaKbSo
drwxrwxrwt 2 root   root  4096 Mar 17 15:00 systemd-private-wD9amr
drwxrwxrwt 2 root   root  4096 Mar 17 15:59 systemd-private-xepYuw
drwxrwxrwt 2 root   root  4096 Mar 17 15:10 systemd-private-zOqpA9


I normally do not reboot this computer, but did so yesterday after a
kernel update.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

David Haller-4
In reply to this post by Carlos E. R.-2
Hello,

On Sun, 05 May 2013, Carlos E. R. wrote:

>On Sunday, 2013-05-05 at 15:39 +0200, Marcus Meissner wrote:
>>No idea about how the clean up works there, if it does not, report
>>a bug I would say :/
>
>It will probably be ignored, or wontfixed, or invalid, or whatever,
>as those files are intentionally not erased:
>
># Exclude namespace mountpoints created with PrivateTmp=yes
>X /tmp/systemd-private-*
>X /var/tmp/systemd-private-*

Sure sign of systemd accumulating too much cruft _already_. That
wooly-egg-laying-milk-giving-sow wannabe.

I think it is a reaally bad idea to let systemd handle ANYTHING more
than the _ONE_ task of basic startup and starting services. And it's
already far beyond that "one task" (gobbling up udev??? WTF?).

-dnh, thinking about using OpenRC, oh, feel free to mail me if you'd
    also be interested in using that for oS ... I guess I'd manage for
    myself, but for the distro, a team is needed.

--
If it is stupid, someone will do it.
If it's really stupid, most people will do it.
If it's unbelievably stupid, everyone will do it.   --  Mike Andrews & Gaz
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Carlos E. R.-2
In reply to this post by Andrei Borzenkov
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Sunday, 2013-05-05 at 18:25 +0400, Andrey Borzenkov wrote:

> There is still corner case when system crashes and leaves those
> directories behind. So I think we still need to at least clean them up
> on reboot.
>
> bor@opensuse:~> cat /etc/tmpfiles.d/remove-systemd-private.conf
> R /tmp/systemd-private-*
> R /var/tmp/systemd-private-*

Creating that file would delete them? When, at boot?

- --
Cheers,
        Carlos E. R.
        (from 12.1 x86_64 "Asparagus" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlGGcxYACgkQtTMYHG2NR9WmYwCeLompAY8oAwrUeoOgnDt+RRVf
sZsAn2hAQzYWkvJTxwUPGNz85Jo0jYSw
=Ky+U
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Andrei Borzenkov
Yes, on reboot. /tmp is already cleaned up periodically, but these directories are explicitly excluded.

Отправлено с iPhone

05.05.2013, в 18:56, "Carlos E. R." <[hidden email]> написал(а):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On Sunday, 2013-05-05 at 18:25 +0400, Andrey Borzenkov wrote:
>
>> There is still corner case when system crashes and leaves those
>> directories behind. So I think we still need to at least clean them up
>> on reboot.
>>
>> bor@opensuse:~> cat /etc/tmpfiles.d/remove-systemd-private.conf
>> R /tmp/systemd-private-*
>> R /var/tmp/systemd-private-*
>
> Creating that file would delete them? When, at boot?
>
> - -- Cheers,
>       Carlos E. R.
>       (from 12.1 x86_64 "Asparagus" at Telcontar)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iEYEARECAAYFAlGGcxYACgkQtTMYHG2NR9WmYwCeLompAY8oAwrUeoOgnDt+RRVf
> sZsAn2hAQzYWkvJTxwUPGNz85Jo0jYSw
> =Ky+U
> -----END PGP SIGNATURE-----
> --
> To unsubscribe, e-mail: [hidden email]
> To contact the owner, e-mail: [hidden email]
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Carlos E. R.-3
In reply to this post by David Haller-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Sunday, 2013-05-05 at 16:51 +0200, David Haller wrote:

> Hello,

> I think it is a reaally bad idea to let systemd handle ANYTHING more
> than the _ONE_ task of basic startup and starting services. And it's
> already far beyond that "one task" (gobbling up udev??? WTF?).

Absolutely.

It breaks the Unix principle of using small programs to do small tasks
with perfection Instead, we have this behemoth, handling system and
services starting, and taking over cron, at, syslog... :-/

> -dnh, thinking about using OpenRC, oh, feel free to mail me if you'd
>    also be interested in using that for oS ... I guess I'd manage for
>    myself, but for the distro, a team is needed.

I guess I'm lazy. I want my comfort zone, to keep using openSUSE as much
as I can... till it is too late, I guess.

- --
Cheers,
        Carlos E. R.
        (from 12.1 x86_64 "Asparagus" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlGGd6EACgkQtTMYHG2NR9UJwACeL5vXHXKWY9R/jxGxRn1+sG+r
m/sAn3MO1Dz799DXvHqREpHVNIB2pKHM
=zQpn
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Several systemd-private-* directories in /tmp

Rüdiger Meier
On Sunday 05 May 2013, Carlos E. R. wrote:

> On Sunday, 2013-05-05 at 16:51 +0200, David Haller wrote:
> > Hello,
> >
> > I think it is a reaally bad idea to let systemd handle ANYTHING
> > more than the _ONE_ task of basic startup and starting services.
> > And it's already far beyond that "one task" (gobbling up udev???
> > WTF?).
>
> Absolutely.
>
> It breaks the Unix principle of using small programs to do small
> tasks with perfection Instead, we have this behemoth, handling system
> and services starting, and taking over cron, at, syslog... :-/

None of the systemd developers like the UNIX idea at all.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

123