Which Debian version do you use?
1 Like
The Internet tells me I find my Debian version with cat /etc/debian_version, which yields 11.9
That’s bullseye. openHABian 1.9 is now based on bookworm. So as said your issue is not related and, well, sorry, off-topic for the most part.
Three options to get the installed OS:
cat /etc/debian_version # only on debian-like systems....
cat /etc/issue
cat /etc/os-release
1 Like
and the fourth 
lsb_release -a
2 Likes
Ah, didn’t know about that one 
tried like the logs:
- downloaded Raspberry Pi Imager (imager_1.8.5.exe)
- selected Pi 4
- selected “openHABian” under “Home assistants and home automation” with date “2024-03-15”
- put the SD-Card in a RasperryPi 4
- after boot up, I still got “bullseye”
Linux openHABMain 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Apr 2 12:58:33 2024 from 192.168.78.20
###############################################################################
############### openhabian ##################################################
###############################################################################
## Ip = 192.168.78.210
## Release = Raspbian GNU/Linux 11 (bullseye)
## Kernel = Linux 6.1.21-v8+
## Platform = Raspberry Pi 4 Model B Rev 1.5
## Uptime = 0 day(s). 00:00:58
## CPU Usage = 37.7% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
## CPU Load = 1m: 2.26, 5m: 0.69, 15m: 0.24
## Memory = Free: 3.09GB (83%), Used: 0.65GB (17%), Total: 3.75GB
## Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
## Root = Free: 22.14GB (81%), Used: 4.90GB (19%), Total: 28.23GB
## Updates = 0 apt updates available.
## Sessions = 1 session(s)
## Processes = 140 running processes of 32768 maximum processes
###############################################################################
_ _ _ ____ _
___ ___ ___ ___ | | | | / \ | __ ) (_) ____ ___
/ _ \ / _ \ / _ \ / _ \ | |_| | / _ \ | _ \ | | / _ \ / _ \
| (_) | (_) | __/| | | || _ | / ___ \ | |_) )| || (_) || | | |
\___/| __/ \___/|_| |_||_| |_|/_/ \_\|____/ |_| \__|_||_| | |
|_| openHAB 4.1.2 - Release Build
Looking for a place to get started? Check out 'sudo openhabian-config' and the
documentation at https://www.openhab.org/docs/installation/openhabian.html
The openHAB dashboard can be reached at http://openHABMain:8080
To interact with openHAB on the command line, execute: 'openhab-cli --help'
Shouldn’t it already get deliverd with bookworm? openHABian is version 1.9
which one, there’s two images
the Pi3 labelled one will not get you bookworm.
There’s only 32.bit and 64.bit? (I chose 32.bit)
I already chose the model in the first step in the imager:
edit: Ah! you mean the 32.bit which is described “like a Pi3”?
I was still under the impression, the 32.bit-version is recommended?
No, read the docs before installing.
I’ll release v1.9b with the 32 bit image in Raspi imager to be the bookworm variant, too.
I did? Does not sound like a unconditonal recommendation to me?
Use the 64 bit image versions but please be aware that 64 bit always has one major drawback: increased memory usage. If you want to go with 64 bit, ensure your RPi has a mimimum of 2 GB, 4 will put you on the safe side. You can use the 32 bit version for older or non official addons that will not work on 64 bit yet.
So, having an Pi 4, 4GB it’s now recommended to use 64-bit? and it solves that annoying 20sec delay after saving a rule…
to be fair it sounds a bit more “soft” than last time I checked for 32 vs 64 bit… 
additional question: how can bindings be checked for 64.bit?
1 Like
I have just released openHABian v1.9c to contain a refactored hotspot setup. Please test.
I recently upgraded to openHABian 1.9c/64 bit running on a Raspberry Pi 5 8 GB. I enabled zram on the new installation. I don’t know if this could be related, but I’m not seeing some issues with logging:
openhabian@openhabian:~ $ ll /var/log/openhab
total 12M
drwxrwxr-x 1 openhab openhabian 4.0K May 3 04:03 ./
drwxr-xr-x 1 root root 4.0K May 3 00:57 ../
-rw-rw-r-- 1 openhab openhab 0 Apr 28 13:18 audit.log
-rw-r--r-- 1 openhab openhab 6.1M May 3 11:11 events.log
-rw-r--r-- 1 openhab openhab 500K Apr 29 19:34 events.log.1.gz
-rw-r--r-- 1 openhab openhab 40K Apr 29 19:49 events.log.2.gz
-rw-r--r-- 1 openhab openhab 522K Apr 30 12:44 events.log.3.gz
-rw-r--r-- 1 openhab openhab 1.1M Apr 30 23:36 events.log.4.gz
-rw-r--r-- 1 openhab openhab 95K May 1 17:58 events.log.5.gz
-rw-r--r-- 1 openhab openhab 651K May 2 11:26 events.log.6.gz
-rw-r--r-- 1 openhab openhab 1.2M May 3 04:03 events.log.7.gz
-rw-r--r-- 1 openhab openhab 1.2M May 1 01:03 openhab.log
-rw-rw-r-- 1 openhab openhab 11K Apr 28 21:40 openhab.log.1.gz
-rw-r--r-- 1 openhab openhab 147K Apr 29 19:34 openhab.log.2.gz
-rwxrwxr-x 1 openhab openhab 0 Mar 23 22:39 Readme.txt*
As you can see, openhab.log hasn’t been updated since 01:03 on May 1st. When this same issue happened previously, it was somewhere between midnight and 1:00 (I restarted openHAB after detecting this).
Since it now happened twice, and given the timestamp, I’m wondering if anyone can point me in the right direction for a solution.
- Could it be zram-related. Should I try to disable again?
- Is there some other log I can inspect to look for any issues around the time where logging apparently got stuck?
- Is there any configuration I can check?
I’m not even sure if I’m asking in the correct thread, but I suspect it might be related to openHABian somehow. I’m running the exact same version of openHAB and with the exact same configuration (backup+restore) as my previous openHABian 1.8/32 bit installation on Raspberry Pi 3.
openHAB version is 4.1.2.
Btw, everything else went pretty smooth. I had only 6 minutes of downtime when switching installation. Kudos to @mstormi for openHABian 1.9!
I’ve seen this at times, too. Should it happen again, try changing loglevel instead of restarting OH, for me that worked.
Try systemctl list-timers --all to see what’s going on at that time.
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. You should be seeing a zsync timer listed when it’s correctly installed.
Thanks, I will try that next time.
I have reinstalled zram, and will keep an eye on this.
No I meant you to enter that cmd right now and check the last rundates.
Isn’t it too late now since it last stopped logging May 1st?
openhabian@openhabian:~ $ systemctl list-timers --all
NEXT LEFT LAST PASSED UNIT ACTIVATES
Sun 2024-05-05 00:00:00 CEST 2h 25min left Sat 2024-05-04 00:00:18 CEST 21h ago dpkg-db-backup.timer dpkg-db-backup.service
Sun 2024-05-05 00:00:00 CEST 2h 25min left Sat 2024-05-04 00:00:18 CEST 21h ago logrotate.timer logrotate.service
Sun 2024-05-05 00:56:43 CEST 3h 22min left Sat 2024-05-04 00:58:08 CEST 20h ago zsync.timer zsync.service
Sun 2024-05-05 03:10:24 CEST 5h 36min left Sun 2024-04-28 13:13:35 CEST 6 days ago e2scrub_all.timer e2scrub_all.service
Sun 2024-05-05 04:31:58 CEST 6h left Sat 2024-05-04 05:37:51 CEST 15h ago firemotd.timer firemotd.service
Sun 2024-05-05 06:51:15 CEST 9h left Sat 2024-05-04 06:30:51 CEST 15h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Sun 2024-05-05 11:21:32 CEST 13h left Sat 2024-05-04 18:25:38 CEST 3h 8min ago apt-daily.timer apt-daily.service
Sun 2024-05-05 11:26:13 CEST 13h left Sat 2024-05-04 04:29:38 CEST 17h ago man-db.timer man-db.service
Sun 2024-05-05 20:06:38 CEST 22h left Sat 2024-05-04 20:06:38 CEST 1h 27min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2024-05-06 00:30:39 CEST 1 day 2h left Mon 2024-04-29 01:39:26 CEST 5 days ago fstrim.timer fstrim.service
It’s meant to find out which timed process was running that might have caused it to stop.
Seems to be zsync only (which wasn’t there by the time it happened as you re-installed it later)
The circumstantial evidence seems a bit stronger now:
openhabian@openhabian:~ $ systemctl list-timers --all
NEXT LEFT LAST PASSED UNIT ACTIVATES
Sun 2024-05-05 11:21:32 CEST 2h 13min left Sat 2024-05-04 18:25:38 CEST 14h ago apt-daily.timer apt-daily.service
Sun 2024-05-05 11:26:13 CEST 2h 17min left Sat 2024-05-04 04:29:38 CEST 1 day 4h ago man-db.timer man-db.service
Sun 2024-05-05 20:06:38 CEST 10h left Sat 2024-05-04 20:06:38 CEST 13h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2024-05-06 00:00:00 CEST 14h left Sun 2024-05-05 00:00:38 CEST 9h ago dpkg-db-backup.timer dpkg-db-backup.service
Mon 2024-05-06 00:00:00 CEST 14h left Sun 2024-05-05 00:00:38 CEST 9h ago logrotate.timer logrotate.service
Mon 2024-05-06 00:30:39 CEST 15h left Mon 2024-04-29 01:39:26 CEST 6 days ago fstrim.timer fstrim.service
Mon 2024-05-06 01:03:41 CEST 15h left Sun 2024-05-05 00:56:51 CEST 8h ago zsync.timer zsync.service
Mon 2024-05-06 02:33:29 CEST 17h left Sun 2024-05-05 04:31:58 CEST 4h 36min ago firemotd.timer firemotd.service
Mon 2024-05-06 06:17:48 CEST 21h left Sun 2024-05-05 06:51:51 CEST 2h 16min ago apt-daily-upgrade.timer apt-daily-upgrade.service
Sun 2024-05-12 03:10:30 CEST 6 days left Sun 2024-05-05 03:10:28 CEST 5h 57min ago e2scrub_all.timer e2scrub_all.service
10 timers listed.
openhabian@openhabian:~ $ ll /var/log/openhab/
total 9.0M
drwxrwxr-x 1 openhab openhabian 4.0K May 5 05:47 ./
drwxr-xr-x 1 root root 4.0K May 5 00:56 ../
-rw-rw-r-- 1 openhab openhab 0 Apr 28 13:18 audit.log
-rw-r--r-- 1 openhab openhab 3.2M May 5 09:08 events.log
-rw-r--r-- 1 openhab openhab 651K May 2 11:26 events.log.1.gz
-rw-r--r-- 1 openhab openhab 1.2M May 3 04:03 events.log.2.gz
-rw-r--r-- 1 openhab openhab 1.3M May 3 20:01 events.log.3.gz
-rw-r--r-- 1 openhab openhab 409K May 4 13:46 events.log.4.gz
-rw-r--r-- 1 openhab openhab 264K May 4 16:01 events.log.5.gz
-rw-r--r-- 1 openhab openhab 13K May 4 16:02 events.log.6.gz
-rw-r--r-- 1 openhab openhab 999K May 5 05:47 events.log.7.gz
-rw-r--r-- 1 openhab openhab 845K May 5 00:56 openhab.log
-rw-rw-r-- 1 openhab openhab 11K Apr 28 21:40 openhab.log.1.gz
-rw-r--r-- 1 openhab openhab 147K Apr 29 19:34 openhab.log.2.gz
-rw-r--r-- 1 openhab openhab 106K May 4 16:02 openhab.log.3.gz
-rwxrwxr-x 1 openhab openhab 0 Mar 23 22:39 Readme.txt*
No it is not because zsync wasn’t there the first times it happened, was it.
Did you try to see if changing loglevel makes a difference ?
I just encountered the same on my box and there it did, logs continue.
(I’m running zsync every hour but logging only stops every now and then.)
You can manually run any timer service such as systemctl start zsync at any time to reproduce.
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.
Unfortunately I wouldn’t know how to approach that and what log settings to use to debug that.
@wborn @kai any idea ? Could you add a periodic check or some such to core logging code ?