Comments (17)
Before #1078 it already was a RollingRandomAccessFile
and I didn't find any note in that PR why it was changed. I'll move this issue to distro.
from openhab-distro.
Maybe you forgot to also update the end tag? 🤔
No but it was an unspotted typo indeed, works now.
EDIT: no issues so far I'd think it's safe to merge
from openhab-distro.
This issue has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/openhabian-testing/147079/128
from openhab-distro.
I commented on another thread but wanted to comment here as well.
Since events.log doesn't seem to have the same problem on a zram sync, maybe switching openhab.log to use a RollingRandomAccessFile appender would work. That's the major difference between events.log and openhab.log in the configs.
from openhab-distro.
It's an issue in the logging framework Log4j2. I've seen this same issue also in other Java applications using Log4j2.
There seems to be a workaround, see:
But it would be better if it is fixed in Log4j2 itself. Maybe you can check the issue tracker if there is an open issue for it and if not create one with enough details so it does not get closed like:
https://issues.apache.org/jira/browse/LOG4J2-3099
from openhab-distro.
That doesn't really address two oddities here.
- Why doesn't the problem effect events.log but only openhab.log?
- Why is openhab.log using a different appender from events.log in the first place?
Given the somewhat hostile response to the issue you link to, I personally don't have much hope that this would ever get fixed upstream since they basically said "you are stupid for deleting the file in the first place, that's not our fault."
It would be informative if someone experiencing this problem could verify whether using the RollingRandomAccessFile appender for openhab.log mitigates this problem. If so, if that appender is good enough for events.log it seem like it should be good enough for openhab.log too unless someone knows why they are different in the first place. So we can mitigate the problem by changing the appender in log4j2.xml here whether or not log4j2.xml ever addresses the problem on their end.
from openhab-distro.
Sure we can workaround it by using another logger.
The different loggers have different implementations which may result in better performance at the expense of using more memory. Something you may not have an abundance of when using ZRAM or RPIs
from openhab-distro.
Sure we can workaround it by using another logger.
As @J-N-K already noted openhab.log
used to be a RollingRandomAccessFile
like events.log
still is.
Log performance isn't an issue.
My first simple attempts to change that in log4j2.xml
failed, though. No openhab.log
logging at all any more, even after OH restart. Please try yourself. You can systemctl start zsync
to provoke the situation when logging stops.
at the expense of using more memory. Something you may not have an abundance of when using ZRAM or RPIs
The stackoverflow link speaks of 256K. These we can spend for sure.
from openhab-distro.
No openhab.log logging at all any more, even after OH restart.
Maybe you forgot to also update the end tag? 🤔
Works fine for me.
from openhab-distro.
Given the somewhat hostile response to the issue you link to, I personally don't have much hope that this would ever get fixed upstream since they basically said "you are stupid for deleting the file in the first place, that's not our fault."
There is a more reasonable response in LOG4J2-3035 which is still open. 🙂
from openhab-distro.
If performance or memory are of concern, according to that StackOverflow post, either RollingRandomAccessFile appender or RollingFile appender can be configured to work similarly in terms of flushing and the size of the buffers. It looks to not be. a problem but if it becomes one we have that option.
What's weird is that on the StackOverflow post and the issue they describe the exact opposite behavior as we are seeing. They are saying that RollingRandomAccessFile appender has problems with logrotate (and their explanation makes sense) but we are actually seeing the problem with RollingFile appender.
Weird and I'm sure it has to do with details in how zram does the flush.
But if it works it works! :-D
from openhab-distro.
But if it works it works! :-D
Yes but seems it does not. I keep seeing the log stop issue at times.
So the logfile type change doesn't do harm but didn't help either (there's others like @holgerfriedrich to report this, too).
I noticed you can issue about any log:set command such as log:set default abcd
to re-activate logging.
So given to wait or attempt convincing the log4j2 people is very unlikely to work, I'm coming back to my original request:
Could you add some sort of periodic logfile handle or logger reinit check that does what issueing log:set does ?
from openhab-distro.
So given to wait or attempt convincing the log4j2 people is very unlikely to work, I'm coming back to my original request
Could you add some sort of periodic logfile handle or logger reinit check that does what issueing log:set does ?
I'd personally rather put effort into fixing it in log4j2 itself instead of creating a workaround that only works with openHAB. That would solve similar issues in other Java applications I develop as well. 😉
from openhab-distro.
I'd personally rather put effort into fixing it in log4j2 itself instead of creating a workaround that only works with openHAB. That would solve similar issues in other Java applications I develop as well. 😉
Then please do and go convince the log4j2 devs yourself. I'm no java dev and I don't have neither the capabilities nor energy to.
Given their hostility on the subject though (see link in history) and that nothing has changed in years I'm pretty sure they will not let themselves be persuaded so that feels like waiting for Godot.
Now short of that being a short term option (if any at all), I'd really appreciate if you could build a fix in openHAB for now to ease user life being affected today.
from openhab-distro.
I'd really appreciate if you could build a fix in openHAB for now to ease user life being affected today.
I don't have time for that now. But if I would have time, I'd rather spend it on fixing the issue in log4j2. 😉
from openhab-distro.
- Why doesn't the problem effect events.log but only openhab.log?
Just for completeness: for me both files are affected by the issue
from openhab-distro.
@openhab/core-maintainers anyone else willing to take on this?
from openhab-distro.
Related Issues (20)
- OH4.1M5: Very very slow first startup and initial exception (HTTP 404) HOT 38
- OH4.1 M5 Failed to process script HOT 13
- openHAB 4.0.4: Changing loglevel via Binding Settings empties org.ops4j.pax.logging.cfg HOT 3
- openHAB 4.1.0 Milestone 5 - Docker - Slow + 100% CPU load HOT 20
- Add ZigBee, ZWave addon.xml data to /runtime/etc/addons.xml HOT 4
- Firefox not working HOT 1
- config.properties not writable in tar.gz HOT 1
- version used for launch/app/pom.xml on tags HOT 1
- Add option to configure SSH public key in $OPENHAB_CONF
- Upgrade Karaf / Jetty to address security issue HOT 2
- Not starting at all HOT 2
- Size of the kar file increased significantly in 4.2 HOT 8
- Incorrect Countries and Regions HOT 1
- [audit.log] Does anything ever get logged to this? Where do failed login attempts get logged? HOT 1
- Error downloading mvn:org.openhab.addons.bundles/org.openhab.persistence.inmemory/4.2.0 HOT 2
- Build 4190 failed HOT 3
- Launching the openHAB runtime... HOT 1
- OH4.3 snapshots: Can't load features repository / Exception while querying feature
- [4.2.0] Addons fail to install due to Apache http OSGI components failing to download HOT 14
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openhab-distro.