Hi Elliot, discussions keep popping up about this, the latest is on the “Mosquitto won't start on boot after raspbian and emonsd update” thread.
Whilst I firmly believe it’s in the hands of the SW providers to make their offerings as robust as possible and being able to overcome a deleted/moved log file would benifit their SW, I also understand we are unlikely to persuade the likes of MySQL, Redis and Apache2 to adopt a change so I also believe it to be a part of the RO optimizations to accommodate this anomaly that exists when moving the log files to tempfs. I do not like the idea of hard coding each SW’s requirements into the emonPi image, but that is how it is done at the moment.
IMO the read-only optimisations should include something to automate the process of replicating any additional log files at boot time regardless of the SW they belong to.
The reason I brought it up here was firstly for clarification as to whether that was still the case, and secondly to make it clear that following the guide outlined in the first post is dependent on the pre-existing “fix” (although I do not think this is a proper fix as the use of rc.local in this way is not recommended and it is depreciated in Stretch) just in case someone lands here via a different route, for example if they partially follow the self-build guide for the emonSD image they may well not have those entries in rc.local.
The guide (although clear and very helpful) only suits pre-built emonSD or non-read-only setups, additional steps are required if installed on a home-brew read-only OS based setup to ensure the logfiles are present before Supervisord service runs.
It would have been nice to have one less SW to worry about, but it’s not the end of the world as we have to accommodate others too as you point out.