Bug 1031325 - systemd leaves private directories in /var/tmp/ after crash
systemd leaves private directories in /var/tmp/ after crash
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-16 15:44 EST by Christian Stadelmann
Modified: 2014-02-24 07:34 EST (History)
7 users (show)

See Also:
Fixed In Version: systemd-208-14.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-24 07:34:38 EST
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 Christian Stadelmann 2013-11-16 15:44:39 EST
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 17:44:31 EST
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 17:50:46 EST
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 18:37:30 EST
(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 06:15:03 EST
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 10:41:15 EST
(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 15:57:22 EST
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 16:15:13 EST
Yeah, title should be updated.
Comment 8 Zbigniew Jędrzejewski-Szmek 2013-12-12 22:42:02 EST
Fixed upstream in http://cgit.freedesktop.org/systemd/systemd/commit/?id=6b46ea73.
Comment 9 Fedora Update System 2014-01-14 20:26:40 EST
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 02:03:04 EST
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 02:39:22 EST
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 10:07:40 EST
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 07:28:09 EST
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 07:34:38 EST
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.

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