Just to correct myself here, I just took a look at the source and it seems a check for
/var/log/emonhub/emonhub.log is still there ahead of resorting to a journalctl search.
SO! The least invasive route by far is to just revert to the init.d script, the emoncms logs will still work and there will be no need to alter rc.local as the init.d script will create the log folder at start up.
This is not intended to be permanent or even progress! Just reverting to something that previously worked without fault for a very long time, until a more complete solution is rolled out.
Just need to stop and disable the current emonhub service, remove the symlink to the service unit, add a symlink to the init.d and then restart and enable the emonhub service again. No files need editing, just a change of symlink and a few systemctl commands.
I looks like we might easily stop more users pulling in the breaking changes (to emonhub) simply by commenting out these 3 lines in the emonpi updater (AFAICT but cannot be sure).
and it is easy to walk someone through reverting the changes manually, we just need a way of scripting a check for the new service unit to trigger a reversion in the update script until such time as we can re-implement the service unit.
I’m happy to look into doing that if there’s an appetite, but I’m not ploughing time into something that is going to be challenged and debated for weeks on end.
My thinking is since this is temporary, lets settle for a known good solution that has worked flwlessly for years rather than slapping more sticking plasters on it, the move to systemd has not brought any benefits at all, only headaches! so there is nothing lost by taking a temporary step back, there is no point in ploughing time into trying to get emonhub working on systemd ahead of a complete overhaul to the logging system. That effort is better channelled towards the permanent solution than creating fixes that will be redundant once a proper solution is rolled out.