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
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.
(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?
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,
(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?
No, we cannot drop systemd-tmpfiles-clean.timer. We must not assume the frequency of shutdowns.
(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?
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.
*** Bug 815805 has been marked as a duplicate of this bug. ***
(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?
(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.)
*** Bug 867652 has been marked as a duplicate of this bug. ***
(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.
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?
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.
/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?
/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
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).
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
This is implemented for F19.
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
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).
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).
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).
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
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).
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).
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.