Update breaks emoncms_mqtt and feedwriter service for non-pi setups

If you do not have an RPi, the latest changes to the services emoncms_mqtt & feedwriter will cause it to fail to start if the ‘pi’ user does not exist.

To fix, you need to sort out these lines

and these

How you fix it will depend on your system.

I said this was a daft way to do it but missed why!!!

Thanks @borpin I note your solution here: emoncms_mqtt service no longer works on non pi systems · Issue #1351 · emoncms/emoncms · GitHub

1 Like

The fix is not 100% correct - just testing :smile:

1 Like

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!

1 Like

Yes I totally agree with this.

Note I did not mention the emonhub service. What has not been done is to use this method!

None - exactly my point and hardcoding the pi as the user is totally inappropriate.