There is absolutely nothing daft about re-using a tried and tested method that has been absolutely robust and reliable for 6 years in the emonhub service. The emonhub service has never been an issue until this was inadvertently removed in the change to systemd and has worked perfectly since it’s reinstatement.
As you can see in your list on the github issue, the mysql logs have a mysql owner, the mosquitto logs have a mosquitto owner, the redis logs have a redis owner, the emonhub logs have a emonhub owner, you see there’s a pattern emerging? All the emoncms logs use a “pi” owner. How many non-rpi systems have a pi user?
The issue is not the way that the pi user is used, it is because the pi user is used. It is on par with installing everything to the /home/pi directory (which is now being done differently). Whether the log files/folders are manually created, auto-created by the service unit, created by a tmpfile or just handled by L2R, they still need ownership and that should not be pi, nor tom, dick or harry, it should be a system user created specifically for emon(cms?) by the installer (or guide) and always present on emoncms installs, regardless of the users name or login.
That system user should then get the right permissions to access the parts of the system it needs to and no more. That way the system user name can be used system wide, across all distro’s, in updates and from within emoncms and it’s scripts etc without editing on a per user basis or being too “pi” orientated.
The “quick’n’dirty fix” is to just create a “pi” system user on non-pi systems, but that is just as wrong as creating a “/home/pi/emonpi” folder on a non-pi server just to be able to utilise the update button in emoncms, which is what I’ve had to do in the past.
The use of tmpfiles is an altogether different discussion.
But undoubtedly, YMMV!