Hmm, what precisely are you echoing into those files? Can you give a complete example please?

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.

On the shell, can you echo them in one step, separated by newlines?

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.

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.

(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.

(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.

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?

(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.