Bug 866693 - Private tmp directories are removed by tmpfiles cleaner
Private tmp directories are removed by tmpfiles cleaner
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
: 894875 925983 (view as bug list)
Depends On:
Blocks: 802465 F18systemd
  Show dependency treegraph
 
Reported: 2012-10-15 17:55 EDT by Tom Hughes
Modified: 2013-08-01 14:38 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 14:38:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Hughes 2012-10-15 17:55:34 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):

systemd-44-17.fc17.i686

How reproducible:

Every time.

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
  
Actual results:

Script fails to write to /tmp.

Expected results:

Script is able to write to /tmp.
Comment 1 Michal Sekletar 2012-12-20 07:55:00 EST
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.
Comment 2 Lennart Poettering 2013-01-14 13:33:46 EST
*** Bug 894875 has been marked as a duplicate of this bug. ***
Comment 3 Ronny Buchmann 2013-01-14 16:31:03 EST
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?
Comment 4 Kay Sievers 2013-01-14 18:02:20 EST
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.
Comment 5 Zbigniew Jędrzejewski-Szmek 2013-01-25 12:39:45 EST
Should be fixed in
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e4ac004
Comment 6 Tom Hughes 2013-01-25 12:56:00 EST
I think you probably want a rule for /var/tmp as well ;-)
Comment 7 Zbigniew Jędrzejewski-Szmek 2013-01-25 13:00:08 EST
I do? I thought that systemd only creates those files in /tmp.
Comment 8 Tom Hughes 2013-01-25 13:28:52 EST
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
Comment 9 Zbigniew Jędrzejewski-Szmek 2013-01-26 11:53:19 EST
(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.
Comment 10 Michal Schmidt 2013-01-28 12:22:38 EST
(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?
Comment 11 Michal Sekletar 2013-02-01 11:11:33 EST
(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.
Comment 12 Michal Schmidt 2013-03-25 03:22:55 EDT
*** Bug 925983 has been marked as a duplicate of this bug. ***
Comment 13 Zbigniew Jędrzejewski-Szmek 2013-03-25 08:34:19 EDT
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.
Comment 14 Fedora End Of Life 2013-07-04 02:57:29 EDT
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.
Comment 15 Greg Scott 2013-07-04 17:30:58 EDT
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
Comment 16 Michal Sekletar 2013-07-22 06:58:16 EDT
(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
Comment 17 Fedora End Of Life 2013-08-01 14:38:31 EDT
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.

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