Bug 1031325

Summary: systemd leaves private directories in /var/tmp/ after crash
Product: [Fedora] Fedora Reporter: Christian Stadelmann <fedora>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: johannbg, lnykryn, msekleta, plautrba, systemd-maint, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemd-208-14.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-24 12:34:38 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:

Description Christian Stadelmann 2013-11-16 20:44:39 UTC
Description of problem:
I've got some empty directories under /var/tmp/ created by systemd. They are not cleaned up.

Version-Release number of selected component (if applicable):
systemd 208

How reproducible:
Always

Steps to Reproduce:
1. reboot Fedora

Actual results:
got a new temporary directory created by systemd, the old one is still there

Expected results:
systemd should delete its old temp dirs

Additional info:
temporary directory naming scheme: /var/tmp/systemd-private-*
they contain nothing than just an empty "tmp" folder.

A similar bug was fixed for F19: https://bugzilla.redhat.com/show_bug.cgi?id=801943
This bug might be related with systemd shutting down incorrectly when using cryptsetup, see https://bugzilla.redhat.com/show_bug.cgi?id=1026119

Comment 1 Zbigniew Jędrzejewski-Szmek 2013-11-16 22:44:31 UTC
We explictly exclude those directories from cleanup because if they are removed, services which are using them as private /var/tmp will break. We properly (afaik) properly clean them up now when stopping services, but we'll never remove them in other situations. So if the machine is reset, those directories will live "forever". It's less of a problem than it might seem, because the contents of those directories is still subject to cleanup, even though the directories themselves are not.

This seems to be design problem with our tmpfiles configuration. One idea would be to add a new setting for time meaning "this boot", which would allow us to clean up everything older then the start of the boot.

Comment 2 Christian Stadelmann 2013-11-16 22:50:46 UTC
Ok, if I correctly understand you this problem consists of two parts:
1. systemd can't safely delete old orphaned directories for the reasons you mentioned. Not a bug in my opinion.
2. those directories should have been deleted at shutdown, but systemd didn't exit properly. Reason is somewhere else (i.e. why did systemd not exit correctly? – could be a hardware reset, …)
Am I right?

Comment 3 Zbigniew Jędrzejewski-Szmek 2013-11-16 23:37:30 UTC
(In reply to Christian Stadelmann from comment #2)
> Ok, if I correctly understand you this problem consists of two parts:
> 1. systemd can't safely delete old orphaned directories for the reasons you
> mentioned. Not a bug in my opinion.
Depending what you mean... It "cannot" delete orphaned directoires, because it is currently not smart enough to know which ones have been orphaned. But it could in principle, e.g. in the way I describe in the second paragraph above.

> 2. those directories should have been deleted at shutdown, but systemd
> didn't exit properly. Reason is somewhere else (i.e. why did systemd not
> exit correctly? – could be a hardware reset, …)
> Am I right?
Yes.

Comment 4 Michal Sekletar 2013-11-17 11:15:03 UTC
Under normal circumstances those dirs should be gone on the next reboot. In case of forceful shutdown they will stay around indefinitely but their content is still cleaned up properly.

I personally don't think there is a compelling need to add new "this boot only option", but feel free to open RFE bug if you think otherwise.

Should we close this as NOTABUG then?

Comment 5 Zbigniew Jędrzejewski-Szmek 2013-11-17 15:41:15 UTC
(In reply to Michal Sekletar from comment #4)
> Should we close this as NOTABUG then?
I don't see why. The issue is clearly valid, out fault, and should be fixed.

Comment 6 Michal Sekletar 2013-11-17 20:57:22 UTC
I was just proposing that we might track this in a separate RFE bug since description of this bug sort of implies that cleanup of systemd-private-*  dirs under /var/tmp doesn't work at all which is (afaik) not the case.

Comment 7 Zbigniew Jędrzejewski-Szmek 2013-11-17 21:15:13 UTC
Yeah, title should be updated.

Comment 8 Zbigniew Jędrzejewski-Szmek 2013-12-13 03:42:02 UTC
Fixed upstream in http://cgit.freedesktop.org/systemd/systemd/commit/?id=6b46ea73.

Comment 9 Fedora Update System 2014-01-15 01:26:40 UTC
systemd-208-11.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-208-11.fc20

Comment 10 Fedora Update System 2014-01-16 07:03:04 UTC
Package systemd-208-11.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-208-11.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-0902/systemd-208-11.fc20
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2014-02-17 07:39:22 UTC
systemd-208-13.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-208-13.fc20

Comment 12 Fedora Update System 2014-02-17 15:07:40 UTC
systemd-208-14.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-208-14.fc20

Comment 13 Christian Stadelmann 2014-02-20 12:28:09 UTC
Seems to be fixed for me. All /var/tmp/systemd-private-* folders get deleted even if my system was unable to cleanly shut down.
Now I only have /var/tmp/systemd-rtkit-daemon.service-* folders.

Comment 14 Fedora Update System 2014-02-24 12:34:38 UTC
systemd-208-14.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.