Hi
I started to use VS Code to tail log file and I noticed that sometimes instead of valid log it presents question marks. It looks like encoding issue. Does anyone have the same issue? Do I need to setup something? I am running it on MacBook Proand OH is running on RaspberryPie
I am having the same issue. Whenever I truncate the log file manually, the next time OpenHAB writes to it there will be corruption. VS Code will eventually get in sync and display the new log lines.
VS Code does not seem to offer a way to choose the encoding type when saving a file. Even if it did, I do not know what type the logger component is using. It is pretty messy unfortunately.
I would like to know what encoding is used, if I can change it and how.
Oh yes it does. Just have a look at the bottom part of your VSCode. There it somewhere (depending on what plugins you have installed) it should state the current encoding. When you click on it you get the options “Reopen with Encoding” and “Save with Encoding”. It’s also described here: Visual Studio Code 0.3.0
Indeed… I tried a lot of them, saving each time after making the choice. Still every time it was updated by OpenHAB it got messed up. I then tried a lot of them to read the messed up file to see if anything readable would emerge. It didn’t. VS always suggest UTF-8 (guessed from content) but it never recognizes the messed up parts.
I then looked at the binary data in the file. The question marks appeared to be all zeros (as in all bits are zero). No text logger should do this.
That seems like an unsurprising outcome. I’m not sure what VSCode would have to do with that.
The OpenHAB logger should just append lines of text to the file, whatever the state of the file. It should not start appending zeros for no reason.
Logging is done by log4j.
As I understand it, this appends to the current file.
If you cut stuff away in service, that all goes wrong.
If this dissatisfies you, I think that’s something to take up with log4j developers.
It does provide a great deal of configuration options, rotation, etc. It’s hard to imagine why anyone would need to edit logfiles.
Maybe this will help -
Yes, that does looks useful. I was just trying to limit the log file size so it would be more convenient to check the latest lines after I try something new in my rules. And apparently this can be done with config files less bluntly then I went about it. Thank you.
VSCode is the wrong tool for reading logs in my opinion. You can either use the “tail” command for this or use some tool like LogExpert, BareTail or any other tail-like tool for your OS.
I’m not entirely sure, but I think log4j locks the log-file as long as the process is running. So you cannot edit the file at all. If you force the file save you might do some “damage” to the file. Comparing config- and log-files is like apples and oranges. The config filse ar written by the user and read by OpenHAB, the logs ar written by OpenHAB and read by the user.
I applied changes to the logger configuration in openhab\userdata\config\org\ops4j\pax\logging.config
(the changes as suggested in the current documentation: Logging | openHAB) but it looks like they are ignored. And, after a restart of OpenHAB they are just gone.
Currently the file org.ops4j.pax.logging.cfg will get overwritten with the default version on every update of openHAB. There is an issue on this.
Well, almost 4 years down the road it no longer requires an update, a simple restart will do.
There are no changes suggested there. We don’t know what you’ve done.
I am sorry, I meant these under " Logging into Separate File", for separate Z-Wave logging:
# ZWave Logger
log4j2.logger.ZWave.name = org.openhab.binding.zwave
log4j2.logger.ZWave.level = INFO
log4j2.logger.ZWave.additivity = false
log4j2.logger.ZWave.appenderRefs = ZWave
log4j2.logger.ZWave.appenderRef.ZWave.ref = ZWAVE
# ZWave File Appender - ZWave.log
log4j2.appender.ZWave.name = ZWAVE
log4j2.appender.ZWave.type = RollingRandomAccessFile
log4j2.appender.ZWave.fileName = ${openhab.logdir}/ZWave.log
log4j2.appender.ZWave.filePattern = ${openhab.logdir}/ZWave.log.%i
log4j2.appender.ZWave.immediateFlush = true
log4j2.appender.ZWave.append = true
log4j2.appender.ZWave.layout.type = PatternLayout
log4j2.appender.ZWave.layout.pattern = %d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n
log4j2.appender.ZWave.policies.type = Policies
log4j2.appender.ZWave.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.ZWave.policies.size.size = 10MB
log4j2.appender.ZWave.strategy.type = DefaultRolloverStrategy
log4j2.appender.ZWave.strategy.max = 10
But I don’t think it matters, the file is just overwritten with the original on each restart. Or I would have to be missing something essential, which is not out of the question.
I just appended these lines to the file and saved: Stopped OpenHAB, modified the file, restarted OpenHAB… and logging.config is back to the original.
There’s a few places in openHAB where xxx.cfg is used as a source for settings, but there also exists a xxx.config version, which can be regarded as the cached or working copy.
All being well, xxx.config would usually get overwritten by xxx.cfg at startup
I don’t know if logging works like that too, but a quote from the docs -
The config file for logging is
org.ops4j.pax.logging.cfg
I noticed the difference but figured it was renamed at some point from one OpenHAB version to the next. I guess I will have to look harder for the cfg incarnation then. Will do, thanks again.
I updated \userdata\etc\org.ops4j.pax.logging.cfg and now the changes persist and I do get a separate ZWave log.
Now it is a matter of digging into log4j to see what my options are to get shorter chunks for the regular info log. Thanks for the hints.