The standard way to handle such issues is to have a file named emonhub-defaults.env or similar in the repo, so that is what gets overwritten in an update. But the running system looks for emonhub.env to get its paths so it can stop with an error message if there is no such file, or perhaps automatically copy the defaults file to the operational file location if it doesn’t exist. That way any customisation is never overwritten accidently.
Not a standard that is currently used here - which is my point.
Oh and the problem with that is, that, unless you load both (unclear if you meant that), if a new variable is added, the file in use does not have that variable. The emoncms settings file is an example of the issues.
I don’t think that’s a serious difficulty. Firstly, I think it will be fairly rare for a new path to be added to the environment; most changes are within existing trees. Secondly, the update can check whether the file in use was modified and if not use the new default. Thirdly, if it was modified then the user clearly understands enough to do that, and likely expects future maintenance and a clear and comprehensive prompt about what needs doing should be enough to get them going.
You have never had to rewrite your settings.php file because a new setting has been added then.
I now have a solution to this here Flexible log_location for emoncms · Issue #1294 · emoncms/emoncms · GitHub. Feel free to discuss on this issue so as not to split the discussion on systemd environment variables.
(I know the first point about emonhub.py path is still under discussion, but) In connection with your recently released fix (Fix for full /var/log issue, causing inputs to stop updating is now available) and the comments in the above mentioned issue, the forth point about the emonhub service creating it’s own log folder/file would, if adopted for the emoncms services too, negate any need for entries in the rc.local for those services, and since feedwriter, emoncms_mqtt and service-runner would all check and create /var/log/emon if required, the folder and emoncms.log would already exist before any webpage is served so /var/log/emon would not need to be created in rc.local in the interim. (as described in /var/log still filling up - #27 by pb66)
Both the emonhub.conf and emonhub.log paths may well be configurable, but the ability to manage it’s own log folder/file is a good addition regardless, it’s more robust, especially when there’s a possibility of it being used with any form of RAM based log partition. The pending decision on paths, should not prevent the unit’s from creating their own log folder/files
With regards to the postprocess,backup,sync module logs and the update logs, these can only work with service-runner active so there is no chance of them being triggered without a log in place. It’s only if emoncms is installed with no services at all that a provision to create the log folder (and file) is needed, that’s not the position on a emonSD so emoncms.log would’nt need creating in rc.local at all.
Could you clarify this? Im not sure that I follow, from my work and testing on this I definetly needed the log folder… e.g /var/log/emon assuming we move the logs to that location.
Remember the log folder issue is not just an emon* problem. Mosquitto and Openhab to name 2 expect the folder that they create at install time to be there but it is lost on reboot because the log folder is on tmpfs.
You do need that folder, but if the service-runner service unit is creating it’s own log folder (which is the same path) you do not need to create the log folder in rc.local or even in the installer/update scripts, and a step further is the feedwriter and emoncms_mqtt services log to emoncms.log (service-runner doesn’t AFAIR) so even though emoncms itself isn’t a service and cannot create it’s own logfolder, either of those services would have.
Just to clarify further, this isn’t a concern for a regular emoncms only custom install as the installer (script or human) can add the folder to /var/log and it will persist, but in the case of emonpi/SD and any other “log in ram” installs, this is more robust, but more to the point here, there is no reason for any emonhub or emoncms logs to be created in the out-going rc.local.
Ah ok, I see what your saying, we make use of each service’s ability to create /var/log/emon, to ensure that in the event that it does get deleted either service-runner or perhaps emoncms_mqtt creates it. Its not reliant on the install script and is therefore more robust. We would still have it in the install script but at least it would get recreated if deleted for some reason.
I agree we are moving away from rc.local, Im only using it on the current image temporarily, given that the logs are in tmpfs without log2ram. Although are you saying it may be safe enough to depend on the service files themselves to handle this on the current image?
After being one of the very few banging on about it for so many years, it is not something I’m likely to forget!!!
Whilst running the likelyhood of sounding like a broken record, log2 ram will address this accros the board. But just because you have a mop and bucket handy, that’s no reason to be careless about spilling stuff on your floor. We know emonhub and emoncms are likely to be installed to a sdcard (tmpfs log) so there is no point in writing weak services, a couple of lines adds a huge amount of robustness. We might not be able to easily change redis, mosquitto and mariadb (hence L2R!) but that’s no reason to be sloppy elsewhere.
1 Like
I would go as far as to say much safer than rc.local.
I do understand rc.local is going to be replaced. I just don’t see why we are avoiding removing the bits that are addressed in code that will be kept moving forward. eg if emonhub is going to create it’s own log folder eventually, why not now? why add the log folder creation to rc.local, it isn’t needed, even temporarily, just make the service robust enough for use with tmpfs logs and jobdone, makeing it vulnerable because rc.local is currently needed for other things just doesn’t make sense to me.
1 Like
Great, makes sense.
@djh could you give an example of how to use the EnvironmentFile to modify the ExecStart= entry in the emonhub.service? This SE suggests using bash to run the command systemd, EnvironmentFile, re-using variables - how? - Unix & Linux Stack Exchange it that how you would do it?
Just on log files, I am seeing this error in daemon.log
May 27 14:17:03 emonpi cron[331]: 2019-05-27 14:17:03 1hVFUs-0000kZ-3g Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=113 egid=117
Do you have an MTA installed? That message looks like it was generated by cron trying to email that something has failed, ordinarily I would expect it to say something like “no MTA installed” but that messages sort of implies there is an MTA installed (exim, included with some Debian distros but not raspbian) but it can’t create it’s log file/folder, perhaps the exim package (if you installed it) created a file and folder but the log in tmpfs lost it on a reboot? Just a guess!
I think it is doable fairly easily by creating the directories/files in the service units (with ExecStartPre). The commands can be inserted into the service units using drop-in files in /etc/systemd/system/<whatever> or even perhaps /run/systemd/system/<whatever>.
I’m not sure why you would need to use bash? Do you have an example of the service file somewhere so we can discuss actualities. I suspect that if you have EMON_HUB_BASE=/some/path in your environment file and ExecStart=$EMON_HUB_BASE/bin/emonhub or whatever in your service unit it will work.
edit: Or ${EMON_HUB_BASE} if required to disambiguate
Yes indeed it is, however in future images we still need L2R to ensure users do not have issues when installing other stuff.
- We should make OUR services as robust as possible, there is no good reason not too.
- We should still install L2R for a more system wide solution to not only logfile creation, but also for persisting log files.
This pretty much means that the other essential services are still covered without the complexity of a overriding “edit” for each service, that’s not to say we absolutely shouldn’t do it, just that it isn’t as easy as writing our own service units and not “essential to make it run” as is the case with the current rc.local mods, L2R works transparently for all (eg possibly exim4 in the preceding posts above).
We could indeed add edit files to each of the servivces restarted in rc.local as a temp fix to the existing image I suppose, but my points above were not aimed as getting shot of rc.local in the existing installs, it was aimed at putting the changes into emonhub and service-runner etc, not holding back because rc.local was still in play.