I reminded Trysrtan of that only just yesterday, my memory might be bad but not that bad!
You are not talking about redirecting per se, you are talking about systemd routing the logfile. I am talking about redirection of stdout and errout as part of the command/script so as to avoid systemd/journald getting involved at all, just like the emonhub setup (with --logfile in the unit) and emoncms. Going back to how the logfiles were generated before everything migrated to systemd.
For example with a shell script you could add
exec 2>&1 1>/var/log/scriptname.log
just under the shebang, or alternatively for a python script
import sys
sys.stdout = open('/var/log/scriptname.log', 'a')
this will put stdout to a logfile directly and doesn’t need the missing systemd directive, plus it doesn’t just leave stdout to be mopped up by journald etc. Although I haven’t tested it, just clarifying what I meant ie NOT using unavailable functions, just common redirection.
I see no reason installing L2R would be problematic, all images have /var/log in tmpfs and if they are a RO OS we can just addsymlinks so the files actually end up in /data (RW partition rather than rootfs)
I think your getting confused there, the rotations are never in RAM with L2R+ (with my olddir mods). The only time you might need additional space in ram to perform the rotations would be if you are using copytruncate which I think we agreed was a bad idea. Avoiding using valuable RAM for rotated logs is precisely why I did the olddir mod to L2R.
I’m sure this is a misunderstanding too, the "Rather than “pulling out” I would favour “not putting in”, comment was aimed squarely at the systemd units that are just letting stdout go to syslog etc emoncms doesn’t use systemd, it’s not a service. I’m referring to service-runner and emoncms-mqtt etc (feedwriter logs direct to emoncms.log now doesn’t it?)
[edit] With regard to logs for emoncms services such as service-runner and emoncms-mqtt, can we please clarify what it is we want? IMO the way the init scripts used to work was spot on. The service start, stops and errors went to journald and the scripts general running logs went to script.log, this was great for debugging and it was consistent with everything else from emonhub and emoncms through to apache2, mosquitto, redis, mysql etc etc etc. Now it seems that we are trying to force all the data together into journald and then possibly filter it out again??? I hope I’m wrong as that seems really bizzare. Plus it is really confusing things.
I feel the move to use emonlogger was right and it IS consistent, what else doesn’t bother managing it’s own log files and expects systemd to do it? I’ve been arguing against emonhub doing that since it was changed to systemd and adding the --logfile arg back in resolves that, AFAIA that only leaves service-runner and maybe emoncms-mqtt that are “inconsistent” and not logging to a logfile directly?
There are comments made like agreeing that these services should have their logs in the /var/log/emoncms folder which make me think we’re on the same page and then there are comments about custom scripts to pull out the logs from the journal that confuse things again, why put them in to the one pot if you have to separate them again? Just don’t put them in! Plus even if we do separate them again, will it not bring the service start/stop/error messages that DO belong in journald out with them, no?