Red Hat Bugzilla – Bug 866693
Private tmp directories are removed by tmpfiles cleaner
Last modified: 2013-08-01 14:38:31 EDT
Description of problem:
If a daemon which uses the PrivateTmp option to run in a private temporary directory has not used it's temporary directory for a while then the tmpfiles logic may remove the systemd-namespace-XXXXXX directory that is the private tmp dir for the daemon.
Then when the daemon does try and write to /tmp it is not able to do so.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start mail server with private tmp directory
2. Wait 10 days
3. Send mail server an email that will be piped into a /tmp using script
Script fails to write to /tmp.
Script is able to write to /tmp.
This was discussed on mailing-list some time ago. It looks like that best approach here would be using single tmp namespace for all processes spawned by service (i.e. processes spawned by ExecStartPre, ExecStart, etc) and each service would clean its own namespace on exit. Secondly we discussed introducing type 'X', meaning that path itself will be skipped on cleanup, but not its content.
Using this approach we will mitigate problems with tmp namespaces, there will be no leftovers from previous runs of service nor deletes of active namespaces which were not used for some time.
*** Bug 894875 has been marked as a duplicate of this bug. ***
In the mailing list there was talk about systemd-tmpfiles only.
Is there any progress in this area?
Anyway, tmpwatch (which is also doing /tmp cleanup) is still pulled in by cups and other packages.
$ repoquery --whatrequires tmpwatch
Is tmpwatch obsoleted by systemd-tmpfiles? So systemd should probably Obsolete: tmpwatch?
cups is fixed in f19. the other packages should also migrate to systemd's tmpfiles.d logic.
the tmpwatch functionality is replaced by systemd, but systemd cannot just obsolete it now, because it's not a drop-in replacement, and does not offer tmpwatch's interfaces, or the other way around: systemd does not provide tmpwatch.
tmpwatch should be removed from the system after everything is migrated.
Should be fixed in
I think you probably want a rule for /var/tmp as well ;-)
I do? I thought that systemd only creates those files in /tmp.
The manual page for PrivateTmp only mentions /tmp but it looks like it does both to me:
bericote [~] % fgrep private /proc/$(pgrep exim)/mountinfo
292 288 0:42 /systemd-private-NbFDjS /tmp rw shared:267 master:36 - tmpfs tmpfs rw
293 248 253:0 /var/tmp/systemd-private-Bf7d8d /var/tmp rw,relatime shared:271 master:1 - ext4 /dev/mapper/bericote-root rw,data=ordered
(In reply to comment #8)
> The manual page for PrivateTmp only mentions /tmp but it looks like it does
> both to me:
> 293 248 253:0 /var/tmp/systemd-private-Bf7d8d /var/tmp rw,relatime
> shared:271 master:1 - ext4 /dev/mapper/bericote-root rw,data=ordered
/var/tmp/systemd-private-* added in http://cgit.freedesktop.org/systemd/systemd/commit/?id=b08131ec. Thanks.
(In reply to comment #1)
> This was discussed on mailing-list some time ago. It looks like that best
> approach here would be using single tmp namespace for all processes spawned
> by service (i.e. processes spawned by ExecStartPre, ExecStart, etc) and each
> service would clean its own namespace on exit.
this part has not been implemented yet, ...
> Secondly we discussed introducing type 'X', meaning that path itself will be
> skipped on cleanup, but not its content.
... but this one has. Does it imply that empty systemd-private-* directories will now accumulate without limits and nothing will ever remove them?
(In reply to comment #10)
> will now accumulate without limits and nothing will ever remove them?
That's correct. However, I've finished the patch and sent it to the mailing list. Review and remarks are very welcome.
*** Bug 925983 has been marked as a duplicate of this bug. ***
Oh, I forgot to update the bug: Michal's patch to remove the directories was merged in http://cgit.freedesktop.org/systemd/systemd/commit/?id=c17ec25e4d9b. Please note that there was an update in http://cgit.freedesktop.org/systemd/systemd/commit/?id=d34cd3749 (an additional directory level was inserted with mode 0700).
The bug should be closed.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
I submitted bug number 925983 back in March and it was marked as a duplicate of this bug. In my case systemd apparently got rid of tmp directories that mysqld needs and this made me crazy for several days after it broke my Wordpress website. But bug 925983 was against F18. I know there are now comments in both bugs about a patch submitted upstream - is it fixed in F19 and was there an F18 back port? And what does the patch do? If layered products need some of those tmp directories to stay alive, will they be OK? How would systemd know which tmp directories to keep and which ones are OK to blow away?
- Greg Scott
(In reply to Greg Scott from comment #15)
> and was there an F18 back port?
IIRC it landed in F18.
> And what does the patch do?
Well, there are two patches related to this issue. One introduced type X for tmpfiles, see man 5 tmpfiles.d. Second unifies tmpfiles handling such that all processes created by Exec directives will share single private tmp directory and this directory will be removed when service is stopped.
> How would systemd know which tmp directories to keep and which ones are OK
> to blow away?
It doesn't care, each service has its own private tmp and it goes away when service is gone. Services shouldn't use /tmp for storing important data.
> - Greg Scott
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.