Bug 1225739
Summary: | RFE: Add age to remove file types opf systemd-tmpfiles | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Fred van Zwieten <fvzwieten> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED ERRATA | QA Contact: | Frantisek Sumsal <fsumsal> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | andre.rozendaal, bblaskov, bbreard, fsumsal, jsynacek, lnykryn, rsawhill, rvdwees, systemd-maint-list |
Target Milestone: | rc | Keywords: | FutureFeature, Patch, Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | systemd-219-35.el7 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-08-01 09:09:52 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1298243, 1383699, 1393867 |
Description
Fred van Zwieten
2015-05-28 07:12:35 UTC
What is the real use-case for this? Usually you want the directory there. application admin installs sap components using sudo. sap leaves install logs in /root in a subdir saplog/. application admins cannot remove those because of permissions. sys admins want this directory cleaned out after x days. If the subdir saplog/ doesn't exist, nothing have to happen. (In reply to Fred van Zwieten from comment #3) Uh this is so wrong. User who does not have access to /root directory runs an application which writes logs to /root? At least please tell you customer to file a bug against sap to move those to /var. Tmpfilesd is about actions which happens repeatedly, what you want to do is just plan some action to the future. Also remove actions are only bound to boot (we only call /usr/bin/systemd-tmpfiles --clean in the timer). I spend quite a lot of time thinking about a sane use-case, but I haven't found one. I really think that introducing such possibility would lead to really bad practices like the one above. (In reply to Lukáš Nykrýn from comment #5) Reopening this bug as I think there is a valid use case. > (In reply to Fred van Zwieten from comment #3) > Uh this is so wrong. User who does not have access to /root directory runs > an application which writes logs to /root? You are absolutely right but there are other uses cases. With RHEL7, systemd-tmpfiles seems to have deprecated tmpwatch. The latter is not installed by default and for example the X11 lock files are now cleaned by /usr/lib/tmpfiles.d/x11.conf. Lets say, the customer just wants to use the new technology as shipped with RHEL7 to clean a file in some directory under, lets say, /var. Though if it doesn't exists (i.e. some application did not create the directory yet), it should not be created as part of a housekeeping job. > Tmpfilesd is about actions which happens repeatedly, what you want to do is > just plan some action to the future. Also remove actions are only bound to > boot (we only call /usr/bin/systemd-tmpfiles --clean in the timer). Yes, and when the r/R type has an age defined, they should be actioned by --clean as well (triggered by the timer). Hi Lukas, Appreciate your feedback on comment#6 with regards to the use case. I believe that what Fred asks for was already implemented upstream: https://github.com/systemd/systemd/commit/df8dee85da5fa41e95dd7f536e67fcc6940a6488 fix merged to upstream staging branch -> https://github.com/lnykryn/systemd-rhel/commit/f2d7881cf56b2d1448b9e09c46c076a14a05011d -> post Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2297 |