Bug 866693
| Summary: | Private tmp directories are removed by tmpfiles cleaner | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Hughes <tom> |
| Component: | systemd | Assignee: | Michal Sekletar <msekleta> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | CC: | gregscott, hill-robert, johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, rhel, ronny-rhbugzilla, samuel-rhbugs, systemd-maint, vpavlin, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-08-01 18:38:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 802465, 871094 | ||
|
Description
Tom Hughes
2012-10-15 21:55:34 UTC
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. http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/6874 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 amavisd-new-0:2.6.6-2.fc17.noarch cups-1:1.5.2-12.fc17.x86_64 cups-1:1.5.4-11.fc17.x86_64 squirrelmail-0:1.4.22-7.fc17.noarch 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 http://cgit.freedesktop.org/systemd/systemd/commit/?id=e4ac004 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. Michal, 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? thanks - 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. > > thanks > > - 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. |