Rule engine not running although bundle active?

Thanks for pointing this out. This was not at all clear for me from the information that I could find online before upgrading. Actually, quite in contrast, there were quite a few posts in this forum which talked about doing exactly what I did: install OH 4, restore a backup from OH 3.x, run the upgradetool. I think it was even you, @rlkoshak, who recommended doing it like this here: Upgrade 3.4 to 4, but how? - #2 by rlkoshak :wink:

Of course I ran the upgradetool after restoring the backup and before starting OH 4 for the first time.

If restoring a 3.x backup (+ running the upgradetool) to migrate a backed-up OH 3.x configuration into OH4 does indeed not (or no longer) work, this might deserve some clear(er) advice in the documentation? If it does work (as several earlier threads indicate), it might be worth pointing out that this is not the case for full backups.

OH 3.4 to 4.0 can work that way but only for non-full backups.

Or you can clear the cache immediately after restoring the full backup but before running anything else (which essentially converts your full backup to a regular backup since the inclusion of cache and tmp is the only difference between a full and a regular backup.

But that was an exception and not guaranteed to work between any arbitrary OH versions down to the first point level (e.g. 4.2 to 4.3 may not work but 4.3.1 to 4.3.2 should work, though you won’t get any of the updates to your installed add-ons if you use a full backup).

Yep, now we seem to have reached consensus. :wink: That’s what I figured out the very hard way.

Therefore, again: a hint in the docs that full backups shouldn’t be used across versions would be very helpful. Or a warning message of the upgradetool, if the cache is not empty. Or a warning message when restoring a full backup into a newer OH version.

Have just added my description to the Github issue.
Have started experiencing this since upgrading to 4.3 from 4.2.
64bit Openhabian, fairly large system, 1100 items, 135 things, >70 JS rules, all files-based.

In my case the issue occurs occasionally (total of six times since upgrade to 4.3, approx every 4th of 5th system restart), but not reproducably. sysctl restart openhabhas so far reliably fixed the issue when it occured. Nothing in the logs that would suggest an error, just that system only gets to runlevel 40 and not beyond, and then rules engine is not loaded. Which leaves the system functioning, but without any automation.

Key difference in my case compared to many of the other reports: virtually no DSL rules. (There was still one (active but unused) one, which I have now deactivated).

I’m not sure where backups and restores are documented in the first place. Not that people read the docs in the first place. But if you know where, there’s a link at the bottom of every documentation page where an edit can be submitted. It’s a great way to contribute to the project.

On a normal upgrade, when upgradetool runs the cache wouldn’t be empty. I think teh cache is cleared as the last step. And you can run upgradetool at any time.

Off topic and sorry to be frank but no!
Upgrade instructions are given where applicable such as in release notes and if users decide to do stuff beyond or ignoring that they must not expect that to work or docs/developers/maintainers to warn them of.

ALL software in general and their docs just don’t work that way.
It’s impossible to list everything one must not do so it remains to be any user’s duty to read and follow the instructions.

Well
 I read up as much as I could before going that step. And all I found indicated not only that this is possible, but even that it’s the recommended way of doing it when you are going to a new machine and a new OH version at the same time. I linked an example above.

Saying that it’s the user’s fault is
 well
 okay. But not if you want this to work for someone who doesn’t spend all their time in the intestines of this particular software.

Oh yes, even and especially in that case. If some user does not want to go the extra mile of understanding the internals and proper context, that’s fine of course.
But then they must be reading the official docs and stick to the documented procedures exclusively and not attempt stuff that’s not officially documented.
So hands off if you don’t find mentioned what you’re about to try.
Note Rich’ post you refer to was a forum post, and forum posts are not part of the official docs.
And on the docs part, I’ll renew my statement that you must not expect any software creator to document any No-Go.
Again, that’s not how any software docs work. It’s on the user to understand that upfront.

Now please get back on the thread topic. What I understood so far is you had a similar symptom after performing some unsupported form of upgrade (which probably caused that in the first place).
Correct? So I don’t think analyzing that contributes to a solution here? or is there anything I missed?

I used the upgrade tool which comes with OH 4.3 and states has the purpose of converting an OH 3.4 configuration to the new version. You are telling me that this despite this tool coming with 4.3 it must under no circumstances be used.

I tried to help. But never mind, I am off.

I have/had many invalid cron
 more than I thought :slight_smile:
I improved the script provided above. More in this post: Script to check Quartz CRON format