tmpfiles.d: add --clean to systemd-tmpfiles-setup.service

[ldzhong]

In some cases users may only want to clean up the files under /tmp during boot and make the following configuration:

cat /etc/tmpfiles.d/fs-tmp.conf
#Type Path Mode User Group Age Argument
d! /tmp 1777 root root 14d

According to the man page of tmpfiles.d
'''
If the exclamation mark ("!") is used, this line is only safe to execute during boot, and can break a running system. Lines without the exclamation mark are presumed to be safe to execute at any time, e.g. on package upgrades. systemd-tmpfiles will take lines with an exclamation mark only into consideration, if the --boot option is given. '''
The option --clean should be added into systemd-tmpfiles-setup.service to make it work as described above.

[github-actions]

Important

An -rc1 tag has been created and a release is being prepared, so please note that PRs introducing new features and APIs will be held back until the new version has been released.

[YHNdnzj]

I'm not sure if this is a valid use case, but at least the same change should be applied to units/user/systemd-tmpfiles-setup.service too.

[ldzhong]

I'm not sure if this is a valid use case, but at least the same change should be applied to units/user/systemd-tmpfiles-setup.service too.

Thanks for your review. We have such a use case reported from our customer. They can't do the cleanup during run time based on their business. So they can't use the time based cleaning process and systemd-tmpfiles-clean.timer & systemd-tmpfiles-clean.service are useless for them. We didn't see any introduction why the "cleanup during boot" can't be done in systemd-tmpfiles-setup.service. Maybe it's an omission?

[bluca]

This seems a bit strange and would break current expectations. Why don't you simply ship your own unit that runs after this one and does the cleanup on boot? I'm not sure this is appropriate for the default, as it would be a change in behaviour

[Werkov]

IIUC the expectations mostly are:

• /tmp is volatile
• /var/tmp is expected to be cleaned up at times, e.g. a sample at reboot

and systemd-tmpfiles-clean.timer has OnBootSec=15min, so the cleanup happens ~15 minutes later anyway in default setups.

[ldzhong]

This seems a bit strange and would break current expectations. Why don't you simply ship your own unit that runs after this one and does the cleanup on boot? I'm not sure this is appropriate for the default, as it would be a change in behaviour

Yes, there will be a change for the default behavior. But I think it's a supplement, so the exclamation mark item in the configuration file can work fully as designed. I guess there's probably some reason why the --clean option is not added into the service file in the beginning. But I didn't find it.

[bluca]

Sure but again: why not simply add a unit in your downstream distribution where this is needed?

[yuwata]

This potentially breaks existing setups...

[Werkov]

This applies to entries marked with ! that are by definition to be run at boot and the effect here is removal of entries that should have been removed by their age parameter.

Can you please be more specific how this can break existing setups? Perhaps, downstream should be cautious about that too.

[ldzhong]

Making such change in downstream is fine, but I think it probably is general enough to be considered as the default behavior. Also any suggestions about the last comment please.

[poettering]

I am not convinced we should add this. A system that doesn't clean-up during runtime basically means you are letting resources to be used unbouned, and that's not a model we want to support.

And we have some prior experience with the cleanup stuff becoming problematic due to unsychronized clocks. i.e. the automatic clean-up is time-based after all, it ages out old files, and that can only work correctly if the local time is set correctly. Because of that systemd-tmpfiles-clean.service is ordered after time-sync.target, to ensure it's not done before the clock is properly synchronized to whatever source is used. With this change this logic loses its effect: you'd clean up already when the clock might very well be garbage.

Hence, I see a major drawback and no real benefit. I am inclined to just say no to this one. Sorry.

[ldzhong]

Thanks for your explanation. I am closing the pull request now.