ZRAM nightly sync, openhab service restart

Hello,

I’m using OH4 with rpi4.
For my shutters and lights I’m using Bticino OpenWebNet binding, and it worked great for last 3 years on OH3. Since clean reinstall to OH4 I’m having difficulties with shutters position.
I’ve noticed that position of all shutters restarts to “UNDEF” during the night, so today I’ve decided to investigate.
I’ve noticed that it happens every day around 1am, and few seconds before reset this is in my syslog:

Nov 28 01:04:56 openhabian systemd[1]: Starting Perform nightly zram sync to persistent storage...
Nov 28 01:04:56 openhabian zram-config[12913]: zram-config sync 2023-11-28-01:04:56-CET
Nov 28 01:04:56 openhabian systemd[1]: Stopping Mosquitto MQTT Broker...
Nov 28 01:04:56 openhabian systemd[1]: mosquitto.service: Succeeded.
Nov 28 01:04:56 openhabian systemd[1]: Stopped Mosquitto MQTT Broker.
Nov 28 01:04:56 openhabian systemd[1]: mosquitto.service: Consumed 1min 5.997s CPU time.
Nov 28 01:04:57 openhabian systemd[1]: Stopping Samba SMB Daemon...
Nov 28 01:04:57 openhabian systemd[1]: smbd.service: Succeeded.
Nov 28 01:04:57 openhabian systemd[1]: Stopped Samba SMB Daemon.
Nov 28 01:04:57 openhabian systemd[1]: smbd.service: Consumed 3.989s CPU time.
Nov 28 01:04:57 openhabian systemd[1]: Stopping Samba NMB Daemon...
Nov 28 01:04:57 openhabian systemd[1]: nmbd.service: Succeeded.
Nov 28 01:04:57 openhabian systemd[1]: Stopped Samba NMB Daemon.
Nov 28 01:04:57 openhabian systemd[1]: nmbd.service: Consumed 1min 14.036s CPU time.
Nov 28 01:04:57 openhabian systemd[1]: Stopping Frontail openHAB instance, reachable at http://openhabian.local:9001...
Nov 28 01:04:57 openhabian systemd[1]: frontail.service: Succeeded.
Nov 28 01:04:57 openhabian systemd[1]: Stopped Frontail openHAB instance, reachable at http://openhabian.local:9001.
Nov 28 01:04:57 openhabian systemd[1]: frontail.service: Consumed 25.465s CPU time.
Nov 28 01:04:57 openhabian systemd[1]: Stopping openHAB - empowering the smart home...

So I went into investigation, why would this happen, since this only stores zram into persistant storage and restarts openhab, but since state is in persistant store it shouldnt matter… or should it?
Well, after checking binding documentation I’ve found this:

  • if openHAB is restarted the binding does not know if a shutter position has changed in the meantime, so its position will be UNDEF. Move the shutter all UP/DOWN to synchronise again its position with the binding

So it all makes sense now, openhab service restarts and resets all positions to UNDEF.

Now to my question, where is zram sync called from and does it need to restart openhab service to work? “crontab -e” is empty. And also times are differing by 5-10min everyday, between 0:55am and 1:05am.

Any ideas?

ty,
Tomi

Welcome to openHAB!
As you are on RPi 4 I recommend to replace your SD card by an USB-SSD and uninstall ZRAM.

I can’t answer the first part but the second part is yes. Otherwise OH might be actively writing while the contents of zram are being dumped and you might end up with corrupted files in the dump.

Unless something has changed in openHABian I’m unaware of, the developer of openHABian actively discourages automatically dumping the zram like this so I wonder if this comes from openHABian in the first place.

The syslog is saying that it’s a systemd cron job. Try looking for a script in /etc/cron.daily or cat /etc/crontab /etc/cron.d/* to see all the jobs scheduled through systemd.

Given that the time isn’t consistent I’m going to guess it’s a script in the cron.daily folder.

Is there a simple migration from SD to USB, or does it require a clean install?

Note, running openHABian on ssd is not supported. It will work for sure but the support you will get from the developers and here on the forum will be limited.

There are two topics which have been discussed in this community: Installing Pi OS on an SSD boot disk and using Pi OS 64bit. Some have still the opinion that it is still advisable to install PiOS 32bit on SD card and activating ZRAM.

As 32bit is the right option for Raspberries with 1GB of RAM, I recommend to install PiOS/bullseye on a SSD and deactivate ZRAM.
The world moved on and more and more users here go for a Pi4 with at least 2 or 4 GB. Then it makes sense to install 64bit PiOS as the first run of a rule takes up to 20 seconds on 32bit and just 2 seconds on 64bit.

Migration is fairly easy. Simply backup oh conf and userdata folder and restore it after a fresh installation (does not apply to apps like mosquitto, persistency databases, etc).
With openhabian it is even easier as you throw the backup zip file into the boot directory and during first-boot it gets automatically restored. Having said this, in the context of openhabian I am not allowed to recommend usage of SSD as boot disk, otherwise this post gets deleted.

1 Like

It’s unclear what you did to your system. Did you reinstall the openhab package only ? Or the OS ?

Syncing ZRAM no longer requires to restart OH so openHABian no longer does this in quite some time. As it obviously does on your system I believe you’re still running an ancient OS setup.

It’s /etc/systemd/system/zsync.service usually calling /usr/local/sbin/zram-config.
You can replace the latter with the latest version from https://github.com/ecdye/zram-config.

Well or you can install everything from scratch on SSD as recommended by some lonely shouters here. But then you will no longer receive help from myself or others on this forum as it’s no longer a supported openHABian setup so if you do and when you’re in need for help then for support please turn to those that recommended doing so.

1 Like

I did a clean reinstall of openhabian OS via RPI imager. From what I see image is from 2023-08-12, so seems recent to me. I did restore openhab configuration which was used on earlier openhabian OS version, but OS was clean.

When I SSH into openhabian, it says:
openHABian
openHAB 4.0.4 - Release Build