[16:36:10] root@openhab:/home/openhabian# date > /var/lib/openhab2/persistence/date
[16:40:12] root@openhab:/home/openhabian# cat /var/lib/openhab2/persistence/date
Sun 30 Aug 16:40:12 CEST 2020
reboot
[16:42:51] root@openhab:/home/openhabian# zramctl
[16:42:56] root@openhab:/home/openhabian# systemctl status zram-config.service
● zram-config.service - zram-config
Loaded: loaded (/etc/systemd/system/zram-config.service; enabled; vendor preset: enabled)
Active: inactive (dead)
[16:43:04] root@openhab:/home/openhabian# cat /var/lib/openhab2/persistence/date
Sun 30 Aug 16:40:12 CEST 2020
this is not correct, is it?
another try:
[16:43:21] root@openhab:/home/openhabian# date > /var/lib/openhab2/persistence/date
[16:44:02] root@openhab:/home/openhabian# cat /var/lib/openhab2/persistence/date
Sun 30 Aug 16:44:02 CEST 2020
reboot
[16:45:44] root@openhab:/home/openhabian# zramctl
[16:45:47] root@openhab:/home/openhabian# systemctl status zram-config.service
● zram-config.service - zram-config
Loaded: loaded (/etc/systemd/system/zram-config.service; enabled; vendor preset: enabled)
Active: inactive (dead)
[16:45:56] root@openhab:/home/openhabian# cat /var/lib/openhab2/persistence/date
Sun 30 Aug 16:44:02 CEST 2020
hmm, i see the correct file, but i don’t think it’s in zram?
ZRAM not starting happens when there’s a circular dependency of services that systemd cannot resolve such as can be seen on L1144 of your log.
The exact start order is coincidential and it is also coincidence where systemd decides to break it.
So sometimes you run into cycles and sometimes you do not.
@narf27 as a test, before you reinstall can you try this with your current test system:
add DefaultDependencies=no in the [Unit] section of all /etc/systemd/system/srv-openhab*.mount
Note the star in the filename so edit all 5 files, after that enter systemctl daemon-reload and reboot to see if zram starts reliably.
If that does not work, remove the files completely then reload,reboot,check again.
If that does not work, remove those After= and WantedBy= lines, too (and no DefaultDependencies line any more), then reload,reboot,check again.
If ZRAM startup succeeds, check what Samba exports. Create a file in /var/log/openhab2/ and see if it appears on the Windows share.
Sep 01 11:38:57 openhab systemd[1]: local-fs.target: Found ordering cycle on srv-openhab2\x2duserdata.mount/start
Sep 01 11:38:57 openhab systemd[1]: local-fs.target: Found dependency on zram-config.service/start
Sep 01 11:38:57 openhab systemd[1]: local-fs.target: Found dependency on sysinit.target/start
Sep 01 11:38:57 openhab systemd[1]: local-fs.target: Found dependency on systemd-tmpfiles-setup.service/start
Sep 01 11:38:57 openhab systemd[1]: local-fs.target: Found dependency on local-fs.target/start
Sep 01 11:38:57 openhab systemd[1]: local-fs.target: Job srv-openhab2\x2duserdata.mount/start deleted to break ordering cycle
Try again with master (but flash again), I’ve just copied the changes from testbuild into master.
I’ve been following along with very little understanding!
But I’m curious if this was a more general issue or something very specific to the environment? I suppose my real question is, are openhabian users getting rubbish restore-on-startup, but don’t realise it?
It’s a general issue hence my persistence in tracking this down.
But there’s a big coincidence factor involved in whether it applies for a specific installation.
So yes some users might have been affected without noticing.
Unless they upgrade to latest master version where it’s fixed.
alright, finally here are my tests with openHAB, mapdb and a testitem:
2020-09-05 14:24:15.693 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T14:24:15.668+0200
reboot
2020-09-05 14:26:16.613 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T14:24:15.000+0200
2020-09-05 15:12:36.723 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T14:24:15.000+0200 to 2020-09-05T15:12:36.712+0200
reboot
2020-09-05 15:14:28.781 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T15:12:36.000+0200
2020-09-05 16:57:47.798 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T15:12:36.000+0200 to 2020-09-05T16:57:47.784+0200
reboot
2020-09-05 16:59:34.772 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T16:57:47.000+0200
2020-09-05 17:02:32.716 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T16:57:47.000+0200 to 2020-09-05T17:02:32.704+0200
reboot
2020-09-05 17:04:19.350 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T17:02:32.000+0200
2020-09-05 17:07:50.566 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T17:02:32.000+0200 to 2020-09-05T17:07:50.542+0200
reboot
2020-09-05 17:09:45.615 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T17:07:50.000+0200
2020-09-05 17:12:42.885 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T17:07:50.000+0200 to 2020-09-05T17:12:42.873+0200
reboot
2020-09-05 17:14:37.189 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T17:12:42.000+0200
2020-09-05 17:25:32.686 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T17:12:42.000+0200 to 2020-09-05T17:25:32.675+0200
reboot
2020-09-05 17:27:04.305 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T17:25:32.000+0200
2020-09-05 17:31:09.773 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T17:25:32.000+0200 to 2020-09-05T17:31:09.759+0200
reboot
2020-09-05 17:32:49.567 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T17:31:09.000+0200
2020-09-05 17:40:37.769 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T17:31:09.000+0200 to 2020-09-05T17:40:37.754+0200
reboot
2020-09-05 17:42:09.763 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T17:40:37.000+0200
2020-09-05 17:43:53.297 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T17:40:37.000+0200 to 2020-09-05T17:43:53.284+0200
reboot
2020-09-05 17:46:22.496 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-05T17:43:53.000+0200
Try uninstalling + reinstalling ZRAM via menu.
Compare files such as /usr/local/sbin/zram-config and /etc/systemd/system/zram* with the ones in the openhabian-zram repo (I just want to be sure they get updated) and try again (some less attempts will do fine a well).
No fundamental change there I’d expect it to still work but I’d like someone to validate.
2020-09-06 12:13:49.114 [vent.ItemStateChangedEvent] - Test changed from 2020-09-05T17:43:53.000+0200 to 2020-09-06T12:13:49.103+0200
reboot ok
2020-09-06 12:15:53.472 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-06T12:13:49.000+0200
2020-09-06 12:21:00.362 [vent.ItemStateChangedEvent] - Test changed from 2020-09-06T12:13:49.000+0200 to 2020-09-06T12:21:00.350+0200
reboot ok
2020-09-06 12:22:31.017 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-06T12:21:00.000+0200
2020-09-06 12:26:22.018 [vent.ItemStateChangedEvent] - Test changed from 2020-09-06T12:21:00.000+0200 to 2020-09-06T12:26:22.004+0200
reboot ok
2020-09-06 12:28:11.544 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-06T12:26:22.000+0200
2020-09-06 12:47:41.902 [vent.ItemStateChangedEvent] - Test changed from 2020-09-06T12:26:22.000+0200 to 2020-09-06T12:47:41.888+0200
reboot not ok!
2020-09-06 12:49:26.167 [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-06T12:26:22.000+0200
2020-09-06 12:47:41.902 ... Test changed ... to 2020-09-06T12:47:41.888+0200
which would have to persist, then reboot, then restore.
2020-09-06 12:49:26.167 ... [vent.ItemStateChangedEvent] - Test changed from NULL to 2020-09-06T12:26:22.000+0200
I’m just suggesting not to leap to the conclusion that the previous change was correctly persisted before reboot. I guess strategy is everyChange? Which should work quite quickly, of course.
I don’t know if the zram version of db gets written to hard storage periodically or when you close system, that might come into play.
It’s difficult to “prove” what goes on because you can’t get a history from mapdb.