Running 3.2 on openHABian on Raspi, my logging to files suddenly stopped for no apparent reason (such as diskspace which is not full).
OH keeps running and log:tail in Karaf console also still keeps working.
Has anyone else encountered this? I was wondering if there could have been some attack attempt on log4j but 'm not directly exposed to the inet, just myopenhab.
Does anyone know how to restart file logging, other than an OH restart ? Any bundle I could restart ?
Hi,
I had the same problem. In my case at /var/log/openhab were several logs like events.log.1 openhab.log.2 etc.
Deleting all the files ending with a number fixed the problem for me.
I’ve not seen this nor seen it reported. Have you tried saving the log4j2.xml file or changing the level of something from the console and then changing it back? That should reset the config for logging which might kick the logging back off again.
Beyond that I don’t really have anything to offer. I know the behavior changed in OH 3 where it starts a new file on every restart of OH in addition to rotating based on log size. But that doesn’t sound like what you are seeing.
I have the same problem. Only sollution for me is openhab restart, no idea how to start logging again.
In my case logging just stops, I didn’t change anything around those moments. Mostly it’s when i’m away from home or in the middle of the night. But, several rules are running offcourse.
Blockquote
Hi,
I had the same problem. In my case at/var/log/openhabwere several logs like events.log.1 openhab.log.2 etc.
Deleting all the files ending with a number fixed the problem for me
Didn’t tried this yet (tried to delete this from the share in windows, but the files wheren’t actually deleted… noticed it after the reboot)
Strange thing, this time i had te reboot the raspberry pi. Restarting openhab didn’t fix it this time.
What you describe strongly indicates that you’ve run out of space on the file system where the logs are stored. If you are running openHABian those are most likely stored in zram. Basically, that means the files are kept in RAM so there is, by design, not a lot of space in those partitions.
zramctl --output-all should tell you.
If needed, increase space in /etc/ztab (zram restart needed) and/or reduce OH log size in log4j.xml.
Thanks! That’s sounds like the reason. I will change those settings to solve this. My logging has grown a lot the last months, never thought zram was to small.
Unfortunately this happened again. I halved the log size from 8mb per file to 4mb per file but again no logs after couple of days. So I checked my zram and this is the output:
openhabian@openhabian:~ $ zramctl --output-all
NAME DISKSIZE DATA COMPR ALGORITHM STREAMS ZERO-PAGES TOTAL MEM-LIMIT MEM-USED MIGRATED MOUNTPOINT
/dev/zram2 600M 386.9M 79.7M zstd 4 841 200M 200M 200M 21B /opt/zram/zram2
/dev/zram1 900M 31.3M 1.5M zstd 4 23 15.6M 300M 15.6M 0B /opt/zram/zram1
/dev/zram0 600M 48.3M 10.8M lzo-rle 4 5778 15.1M 200M 20.4M 311B [SWAP]
I’m not sure how to read this. Look like the disksize is big enough, but Total Mem and Mem limit is 200M for /dev/zram2.
It could be I disabled zram a while ago but I can’t remember. I run Openhabian on an SSD drive so ZRAM isn’t necessary. But for now I just chose the option Use Zram in openhabian-config.
Does anyone know if the problem is within zram or there something else wrong?
p.s. I checked the space of all the disks of the raspberry filesystem and there is plenty of space left (most drives have 1% to 10% in use, zram 42% use).
Ugh. That now is a not recommended and not. supported modification. I’d guess it’s well related to your issue but as noone but you knows about whatever changes and steps you went to get there and when i.e. what openHABian codebase you applied them to, noone can tell how these mods affect logging, zram and all.
As the docs warned, you’re on your own here from now on.
I think you’re to fast with your conclusions. I’m using and SSD since openhab 2.5 (openhabian) without any problems. Using an SSD on a pi is just flashing the image to the SSD in stead of an microSD card, and some other minor changes. Sure it works a bit different, but not wanting to help because someone does something a bit different then what you are use to, is a bit harsh.
This problem exist since version 3.2 for me, so one could know the SSD is certainly not the reason of this behaviour.
I’m very disappointed on how you react on this, especialy the “ugh” part…
I hope I will find the problem, when I know what this caused, i will report it here.
By the way, I think it’s very good to use an SSD because is much more reliable (yes I know about backup, but prefent is better than repear). We should encourage people to use SSD is my humble opinion.
Interesting response.
FYI in case you are not aware, you’re telling the openHABian maintainer.
Right, that guy who has put countless hours of voluntary work into making openHABian, ZRAM and all that work for you and who tried and tested countless configurations in trying to get as many devices to work reliably in an even automatically provisioned fashion, ever again running into issues for -again- your benefit.
That guy that has spent even more hours supporting people for free, doing so based on the assumption they run a default system because they didn’t tell otherwise upfront, then not always but quite often it turned out those people’s issues were because of their modifications.
So you, who ignored the prerequisites and statements on SSD support and ZRAM in the first place including our request for fairness, now are “disappointed” just because that guy now dares to respond “Ugh” and does not want to waste any more of his spare time on right this ?
Interesting indeed.
The problem was the memory limit from ZRAM. The sollution I used was disabling ZRAM and the problem has been solved for me. Because I use an SSD, ZRAM doesn’t do much, though for some specific moments, using ZRAM makes the RPi a tiny bit faster.
Hope I can help someone with this anwser!
I had the same problem (standard installation: openhabian on raspi with ssd and logs in zram).
It always happened when I forgot to turn down extensive logging after some debugging research (e.g. zigbee-logging to info).
After deleting some big logs and turning down log levels to normal the problem completely went away. (That’s why i never chased the root cause)