FS#30384 - [systemd-tools] systemd-tmpfiles --clean doesn't clean tmp files

Attached to Project: Arch Linux
Opened by Lukas Jirkovsky (6xx) - Wednesday, 20 June 2012, 17:02 GMT
Last edited by Dave Reisner (falconindy) - Monday, 03 September 2012, 15:00 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

When I set the /etc/tmpfiles.d/tmp.conf to:

d /tmp 1777 root root 0d
d /var/tmp 1777 root root 0d

No files are cleaned up by the systemd-tmpfiles --clean (executed by initscripts). Using a short time interval such a 1s doesn't work either.

It should be noted that the tool probably scans the disk, because when the /tmp contains a lot of files, it doesn't return immediately but rather it runs for a few seconds.

Additional info:
systemd-tools 185-1
initscripts 2012.06.1-1
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 03 September 2012, 15:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed upstream at some point
Comment by Dave Reisner (falconindy) - Monday, 13 August 2012, 00:11 GMT
Is this still a valid bug?
Comment by Lukas Jirkovsky (6xx) - Monday, 13 August 2012, 07:35 GMT
Unfortunately it still is.
Comment by Dave Reisner (falconindy) - Wednesday, 29 August 2012, 14:31 GMT
What sort of mount options do you have on /tmp?
Comment by Lukas Jirkovsky (6xx) - Monday, 03 September 2012, 12:21 GMT
/dev/sda1 on /tmp type ext4 (rw,noatime,data=ordered)

I forgot to note that I have /tmp on a separate partition – I thought I mentioned it, but it seems I did that only on ML.
Comment by Tom Gundersen (tomegun) - Monday, 03 September 2012, 12:40 GMT
I can confirm that setting the Age parameter to 0 never works, so please only test with 1s.

When /tmp is a separate partition (and a real block device, not a tmpfs), then files in /tmp are cleaned up, but not the subfolders of /tmp. If /tmp is not a separate partition, or a tmpfs then it works as expected.
Comment by Tom Gundersen (tomegun) - Monday, 03 September 2012, 12:48 GMT
I take that back. It turns out that the lost+found folder is ignored, but not regular folders. Is this what you see? What sort of files/dirs are not cleared for you?

In short: I cannot reproduce.
Comment by Lukas Jirkovsky (6xx) - Monday, 03 September 2012, 13:49 GMT
With 0d nothing seems to be cleaned up (there's still a ton of files). With 1s most of the files are cleaned up, but chroots created using mkarchroot are not removed. The errors are present in all cases. They errors were shown even when I cleaned up /tmp manually.
Comment by Tom Gundersen (tomegun) - Monday, 03 September 2012, 13:52 GMT
I just posted a patch for the 0d bug: http://lists.freedesktop.org/archives/systemd-devel/2012-September/006421.html.

Is something mounted on your chroot folders? What do you mean by "The errors are present in all cases. They errors were shown even when I cleaned up /tmp manually."?
Comment by Dave Reisner (falconindy) - Monday, 03 September 2012, 13:55 GMT
I believe the noatime flag is why this doesn't work. Please try again with relatime or strictatime.
Comment by Lukas Jirkovsky (6xx) - Monday, 03 September 2012, 14:08 GMT
Tom: sorry, I accidentally messed this bug with the bug #30893, that's why I was referring to "the errors". There's nothing mounted in the chroots - it happens with freshly created chroots, too. I'll try the patch you posted.

Dave: I'll try that if the Tom's patch won't help. But I'm convinced that systemd-tmpfiles should be able to cope with /tmp being noatime.
Comment by Dave Reisner (falconindy) - Monday, 03 September 2012, 14:27 GMT
tmpfiles computes age of any given file as the maximum of the atime, mtime, and ctime. If you have files that still aren't cleaned, the full output of 'stat' on those files would be interesting.
Comment by Lukas Jirkovsky (6xx) - Monday, 03 September 2012, 14:41 GMT
This bug was fixed. I think it has been fixed for some time now, but because of the  FS#30893  it was not apparent.

Loading...