Surely the service unit could create the folder if it is needed? Just do it as an ExecStartPre.
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.
1 Like
I would of thought so too, I suggested this way back, in the form of a ārequirementā for emonhub to make the change to systemd. Thatās pretty much why the emonhub systemd change was on hold, then Trystan decided to go ahead anyway and just rely on systemd to handle the stdout, hence we are where we are.
I have no idea if that would definitely work ok, I forget why there was resistance when I said the service unit should create the log folder, it was a long time ago. It would need to create the folder with the right ownership/permissions, but yes that would (if it works) be an easier solution, providing itās easy to set up and doesnāt cause any issues that need further fixes, again, it might be better to revert to a known good position temporarily until a full solution is rolled out rather than ploughing time into further developing a new temporary fix.
We just need to get on with it rather than debate 101 different ways to do it! If we have rolled back that change as soon as Brian noted the issue, many users would never have been exposed to it. Because of the debate on how to move forward (rather than a swift and temporary step back) many users now have the issue and we now also need to formulate a update procedure to fix or undo something that could have been nipped in the bud before being widely deployed.
Just to action something! I have just created a PR to stop more users falling into the same trap, just until we have a better fix.
It doesnāt fix broken setupās, but perhaps more importantly right now, it prevents breaking working setups further.