Bug 90455 - RFE: tmpfiles: allow multiple "w" lines for the same file, as long as they share all the same attributes (with the exception of the final argument to write)
Summary: RFE: tmpfiles: allow multiple "w" lines for the same file, as long as they sh...
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-14 19:42 UTC by Sergio Durigan Junior
Modified: 2016-10-22 09:01 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergio Durigan Junior 2015-05-14 19:42:33 UTC
[ I could not find any bugs opened for this "feature request", so I am opening this now.  Apologies if this has been discussed already. ]

I was trying to use /etc/tmpfiles.d/ (systemd-tmpfiles) to set some flags on /proc/acpi/wakeup, and I noticed that only the first flag was being set.  After some investigation, I found that systemd-tmpfiles does not accept when you specify multiple entries with the same path on a *.conf file.  This behavior is described in the manpage, but I still think systemd-tmpfiles should accept this kind of input (which is pretty normal if you are doing what I did, i.e., pass a set of flags to some file under /proc).

Thank you.
Comment 1 Lennart Poettering 2015-05-14 20:03:32 UTC
Hmm, what precisely are you echoing into those files? Can you give a complete example please?
Comment 2 Sergio Durigan Junior 2015-05-14 20:11:03 UTC
Sure.  For example:

w /proc/acpi/wakeup - - - - TSCR
w /proc/acpi/wakeup - - - - TPAD

I actually had 4 lines like those in the file, each one setting different things on /proc/acpi/wakeup.  Only the first one gets processed.
Comment 3 Lennart Poettering 2015-05-14 20:15:59 UTC
On the shell, can you echo them in one step, separated by newlines?
Comment 4 Sergio Durigan Junior 2015-05-14 20:25:58 UTC
Yes, I can.  I know that systemd-tmpfiles also accept "\n" when specifying the value, and I forgot to mention that this is what I ended up doing to "fix" the issue.  But I wonder if there is any technical reason for not accepting multiple entries with the same path.  My impression is that the user thinks this is more natural than using "\n" explicitly, and I actually found some websites that are (wrongly) teaching users to use tmpfiles.d like this.
Comment 5 Lennart Poettering 2015-05-14 20:47:57 UTC
Well, if you have one line that sets the access mode to 0755 for a file, and another one which sets it to 0777, what do you do? It's not clear what actually should happen in that case, hence we generally report errors about conflicting lines.

That said, we allow multiple completely identical lines already, and we do allow to combine multiple lines that set xattrs, acls, with other lines.

Maybe we could allow multiple w lines too, as long as everything they declare match, with the exception of the final argument.
Comment 6 Sergio Durigan Junior 2015-05-14 20:54:09 UTC
(In reply to Lennart Poettering from comment #5)
> Well, if you have one line that sets the access mode to 0755 for a file, and
> another one which sets it to 0777, what do you do? It's not clear what
> actually should happen in that case, hence we generally report errors about
> conflicting lines.

I am not a systemd developer, so I may be talking BS here, but in this case it seems to me that the *.conf file should be processed line-by-line, i.e., the order matters, so if you are setting the mode to 0755 and then to 0777, the last one "wins".  Of course, there may be cases when the lines are really conflicting, in the sense that they do things incoherently, but that is a user error, not exactly a systemd concern.
 
> That said, we allow multiple completely identical lines already, and we do
> allow to combine multiple lines that set xattrs, acls, with other lines.

Cool.

> Maybe we could allow multiple w lines too, as long as everything they
> declare match, with the exception of the final argument.

That sounds like a good plan to me.  Thank you for adjusting the title to reflect this.
Comment 7 Lennart Poettering 2015-05-15 09:44:02 UTC
(In reply to Sergio Durigan Junior from comment #6)
> (In reply to Lennart Poettering from comment #5)
> > Well, if you have one line that sets the access mode to 0755 for a file, and
> > another one which sets it to 0777, what do you do? It's not clear what
> > actually should happen in that case, hence we generally report errors about
> > conflicting lines.
> 
> I am not a systemd developer, so I may be talking BS here, but in this case
> it seems to me that the *.conf file should be processed line-by-line, i.e.,
> the order matters, so if you are setting the mode to 0755 and then to 0777,
> the last one "wins".  

Well, currently the first one wins, plus you get a message informing you about the conflict. I think that's pretty OK already.
Comment 8 Zbigniew Jedrzejewski-Szmek 2015-05-15 12:51:46 UTC
It would be nicer to write separate values on separate lines than to use "\n". Especially when you have more than a few values to write. So it would be good to support this in some way, but it's an edge case.

Maybe we should add 'W' which writes all the values in turn?
Comment 9 Sergio Durigan Junior 2015-05-15 18:17:21 UTC
(In reply to Lennart Poettering from comment #7)
> Well, currently the first one wins, plus you get a message informing you
> about the conflict. I think that's pretty OK already.

Hm, but the message may be misleading, and in fact I think it is, most of the time.  I mean, I tried to use tmpfiles.d as a replacement for a rc.local script that does "echo BLA > file", and I think most users have the same usecase.  Fortunately, 'echo BLA > file' doesn't try to be smarter than you and detect possible conflicts (e.g., when you use multiple echo's to the same file).

On a related note, I liked the idea of the new 'W' parameter for a DWIM version.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.