Okay, I’m a bit confused now. I wrote that based on the fact the it always happens around that time, and this night I now know it happened exactly at that time. I didn’t fully get this:
I doubt it’s zram (which indeed would run around that time) because there was a bug that it didn’t install fully the zsync part. I just fixed that, you could attempt to interactively re-install that from the menu.
When you write “didn’t install fully”, I thought it may still have installed it partially? I don’t know which parts were installed and which were not.
What I’m referring to is only a relation to zram/zsync and the job/timer for that. I don’t know the details, so I’m not pointing towards anything more specific than that.
How to proceed? If you are 100% sure it’s not related to any of that, my logical next step will be to uninstall zram from openhabian-config and monitor the results from that.
If you believe there could be some kind of relation, I’d be happy to assist in reproducing.
Note zsync unmounts the logdir so it stops systemd and various processes that might be accessing that. I believe there eventually is a problem with running openhab java handling the situation after the
openhab.log
file handle is gone on unmount. Yet it seems to properly recover when that’s back.
This is also my feeling. Perhaps it only recovers when nothing is written to the logfile while the logdir is unmounted? Sometimes this will probably be the case. For me it seems to consistently fail, so maybe I’m logging more stuff continuously, increasing the risk of writing something just at the crucial moment.