Bug 801943 - remove empty private tmp directories after use
Summary: remove empty private tmp directories after use
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
(Show other bugs)
Version: 19
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 815805 867652 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-09 22:16 UTC by Michal Jaegermann
Modified: 2013-05-16 02:59 UTC (History)
21 users (show)

Fixed In Version: systemd-201-2.fc18.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-16 02:59:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Michal Jaegermann 2012-03-09 22:16:21 UTC
Description of problem:

I am not sure when this started to happen but relatively recently directories
/tmp/systemd-namespace-<pattern> started to show up in great numbers.  Each of these contains subdirectories 'private' and 'root' but otherwise it is empty.
Nothing appears to drop them, or at least not fast enough for a rawhide installation which gets rebooted quite often, and all these leftovers are growing quite quickly.

Mounting /tmp from RAM would surely help but I could use more memory even right now so this is not an attractive proposition.

Version-Release number of selected component (if applicable):
systemd-43-2.fc18

Comment 1 Lennart Poettering 2012-03-12 13:32:16 UTC
These directories are created by the PrivateTmp feature, and exist at least as long as the service which they have been created for is running.

Normally they should be cleaned up by systemd-tmpfiles eventually.

Comment 2 Michal Jaegermann 2012-03-12 15:50:09 UTC
(In reply to comment #1)

> Normally they should be cleaned up by systemd-tmpfiles eventually.

It is not clear what "eventually" may really mean here.  I got a surprise
by finding something like of an order of forty of these, with different dates and all basically empty. Most likely if I would not happen to look it would be more in a short order. /tmp itself already grew up considerably and once that happened there is no simple way to shrink it.  Directories do not do it by themselves and "copy-and-replace" bumps into "busy".

Naybe systemd-tmpfiles is just too relaxed?

Comment 3 Assen Totin 2012-07-23 09:21:23 UTC
Hi,

I can confirm this problem still exists in Fedora 17 with all updates as of the day of this posting.

After a few months of running a desktop system (which is powered off/on each day), /tmp becomes rather cluttered with systemd-namespace-xxxxx directories. 

Not sure if this is systemd or Fedora issue, but would be nice if systemd on Fedora could clean up after itself. 

WWell,

Comment 4 Jóhann B. Guðmundsson 2012-07-23 11:17:56 UTC
(In reply to comment #1)
> These directories are created by the PrivateTmp feature, and exist at least
> as long as the service which they have been created for is running.
> 
> Normally they should be cleaned up by systemd-tmpfiles eventually.

Hmm that sounds a bit backwards should they be cleaned on shutdown and the systemd-tmpfiles-clean.timer simply be dropped?

Comment 5 Michal Schmidt 2012-07-23 11:41:08 UTC
No, we cannot drop systemd-tmpfiles-clean.timer. We must not assume the frequency of shutdowns.

Comment 6 Jóhann B. Guðmundsson 2012-07-23 12:45:14 UTC
(In reply to comment #5)
> No, we cannot drop systemd-tmpfiles-clean.timer. We must not assume the
> frequency of shutdowns.

Ah true for the user base who rarely turn off or reboot but we can cleanup always on shutdown right?

Comment 7 Michal Schmidt 2012-07-23 13:11:20 UTC
With /tmp on tmpfs, the cleanup on shutdown is ensured.

Anyway, relying solely on either systemd-tmpfiles or cleanup-on-shutdown is a mistake. They should be considered only secondary mechanisms for cleaning up.
The primary cleaning mechanism should be systemd removing the empty namespace directories as soon as they're not used anymore.

Comment 8 Michal Schmidt 2012-07-26 08:45:27 UTC
*** Bug 815805 has been marked as a duplicate of this bug. ***

Comment 9 Lennart Poettering 2012-09-14 15:13:37 UTC
(In reply to comment #7)
> With /tmp on tmpfs, the cleanup on shutdown is ensured.
> 
> Anyway, relying solely on either systemd-tmpfiles or cleanup-on-shutdown is
> a mistake. They should be considered only secondary mechanisms for cleaning
> up.
> The primary cleaning mechanism should be systemd removing the empty
> namespace directories as soon as they're not used anymore.

Hmm, for non-PrivateTmp= service we can't do automatic cleanup, and hence don't do it. If we did that for PrivateTmp= services, wouldn't that be a weird asymmetry?

Comment 10 Michal Schmidt 2012-10-19 09:26:28 UTC
(In reply to comment #9)
> Hmm, for non-PrivateTmp= service we can't do automatic cleanup, and hence
> don't do it. If we did that for PrivateTmp= services, wouldn't that be a
> weird asymmetry?

No, there would be symmetry: What we mkdir() when starting a service, we should rmdir() when the service stops. (Only if the directory is not empty at the time, we can let it be.)

Comment 11 Michal Schmidt 2012-10-19 09:26:51 UTC
*** Bug 867652 has been marked as a duplicate of this bug. ***

Comment 12 John Reiser 2012-10-19 16:33:04 UTC
(In reply to comment #10)
>  What we mkdir() when starting a service, we should rmdir() when the service stops.

I agree; do not leave garbage as a matter of course.  Going around the garbage slows down sysadmin chores of checking on resource utilization, debugging other services, etc.  Also, garbage costs cycles: lookups are slower when a directory has hundreds of "unused" entries.

Besides, the reaper:
   1) apparently reclaims S_IFREG files only, not directories
   2) lacks functionality such as 'anacron': catch up with chores if the regular schedule gets interrupted (crash, power fail, shutdown, clock adjustment, ...)
   3) does not keep up with a on-demand service which may start and stop many times (thousands) during a "normal" day.

Comment 13 SpuyMore 2013-01-17 09:53:43 UTC
I just noticed I have thousands of these leftover systemd-* directories in my /var/tmp, and some in /tmp as well. Is this issue being worked on?

Comment 14 Henrique Martins 2013-01-17 15:34:03 UTC
I think /tmp and maybe /var/tmp, will be mounted as tmpfs as of Fedora 18, thus rebooting will clean it up :-)  
Won't solve your problem if you keep your system up for a long time.

Comment 15 SpuyMore 2013-01-17 15:42:18 UTC
/tmp is indeed tmpf, but /var/tmp is not and that's where I found the thousands of files. I haven't altered any file systems and mount options so I gues F18 does not make /var/tmp a tmpfs by default. Should it?

Comment 16 Cristian Ciupitu 2013-01-17 22:07:23 UTC
/var/tmp can't be a tmpfs because it's for temporary files preserved between system reboots according to the Filesystem Hierarchy Standard (FHS) [1].

[1] http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE

Comment 17 Carl Roth 2013-01-28 18:39:44 UTC
Today one of my systems (F17) had trouble booting because its /tmp filesystem ran out of inodes...  Cleaning out old, empty directories corrected the issue:

  # cd /tmp                                                                                                                                                           
  # find . -depth -type d -mtime +10 -print0 \                                                                                                                        
    | xargs -0 -i rmdir "{}"                                                                                                                                          

Moving /tmp to tmpfs as in F18 may not help (unless tmpfs supports an infinite number of inodes).

Comment 18 Fedora End Of Life 2013-04-03 17:44:34 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 19 Lennart Poettering 2013-04-09 11:33:42 UTC
This is implemented for F19.

Comment 20 Fedora Update System 2013-04-10 20:15:30 UTC
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1

Comment 21 Fedora Update System 2013-04-11 23:28:37 UTC
Package systemd-201-2.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2
then log in and leave karma (feedback).

Comment 22 Fedora Update System 2013-04-16 00:03:15 UTC
Package systemd-201-2.fc18.4:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.4
then log in and leave karma (feedback).

Comment 23 Fedora Update System 2013-04-18 02:40:50 UTC
Package systemd-201-2.fc18.5:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5
then log in and leave karma (feedback).

Comment 24 Fedora Update System 2013-05-07 13:42:46 UTC
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6

Comment 25 Fedora Update System 2013-05-09 10:04:31 UTC
Package systemd-201-2.fc18.6:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
then log in and leave karma (feedback).

Comment 26 SpuyMore 2013-05-10 09:54:05 UTC
Works for me, thanks.

(In reply to comment #25)
> Package systemd-201-2.fc18.6:
> * should fix your issue,
> * was pushed to the Fedora 18 testing repository,
> * should be available at your local mirror within two days.
> Update it with:
> # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6'
> as soon as you are able to.
> Please go to the following url:
> https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
> then log in and leave karma (feedback).

Comment 27 Fedora Update System 2013-05-16 02:59:57 UTC
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


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