Cleaning up the startup process / renaming rules (windows possible)

Just upgraded to latest snapshot and noticed this line went missing, apparently openhab2.service gets overwritten.
So we should think of a different method of ‘anchoring’ the move script.

1 Like

Added 2 variants of the process. If you used the prior version, please have in mind, that i changed the suffix for unused rules from “rulesx” to “rules_away”.

Hi @job,

I like to come back an this topic with my current solution. Now it’s also tested and at least working for me :wink:

But first let me recommend to not alter the upstream version of the openhab2.service file. Instead I would go with an override of the same. One can do this with

sudo systemctl edit openhab2.service

That will create a new file /etc/systemd/system/openhab2.service.d/override.conf with all the content you like. This file will survive also an upgrade of openhab to the next version.

To undo such a change you can also activate the original state with

sudo systemctl revert openhab2.service

The content of the file may e.g. be (according Alternative 3 from the first post):

[Service]
ExecStartPre=/etc/openhab2/exec-scripts/moverules.sh rules rules_away
ExecStartPost=/bin/sleep 240
ExecStartPost=/etc/openhab2/exec-scripts/moverules.sh rules_away rules

Next we want to

sudo systemctl daemon-reload

Now, another alternative is to go with this override to the openhab2.service

[Service]
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.rules" -exec /usr/bin/rename.ul .rules .x {} \\;'
ExecStartPost=-/bin/sleep 90
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.x" -exec /usr/bin/rename.ul .x .rules {} \\;'
TimeoutStartSec=180

Well, TimeoutStartSec is optional, but I found it useful to prevent the openhab2.service to go into failed-state due to long startup times. I’ve set this value to the duration of the sleep (90 seconds) plus another 90 seconds.

9 Likes

:+1:

Nice, @ptweety.

That’s a great approach. Your approach will replace Alternative 2+3, if you don’t mind.

No rules, no shell schript, just a small override to the service configuration. Great!

Thanks.

Nice approach but seems it’s not applicable everywhere. I’m running a Jessie based openHABian which I believe is the most common Linux variant to find among OH users.

[14:25:55] root@openHABianPi:/home/pi# systemctl list-unit-files openhab2.service
UNIT FILE        STATE
openhab2.service enabled

1 unit files listed.
[14:25:58] root@openHABianPi:/home/pi# systemctl edit  openhab2.service
Unknown operation 'edit'.
[14:26:08] root@openHABianPi:/home/pi#

Hi @mstormi,

with debian jessie you have an outdated version of systemd that does not support systemctl edit. But you can create the folders for your services and your own override.conf file by yourself.

sudo mkdir /etc/systemd/system/openhab2.service.d
sudo nano /etc/systemd/system/openhab2.service.d/override.conf
4 Likes

Thanks @job this certainly makes startup much faster and more stable.

As a side it also meant I could use a new naming convention on my rule files so that I could control loading order as well. Just suffixed everything with a numeric like:

nnn-myrule.rules

Also added a little sleep (1 second for now) in between each ‘mv’ (or in my case ‘ln’) so OH has a little breather as it picks up each file. Still playing with whether it is worth it and how long to sleep but just felt it was better than dumping the whole ‘rules’ loading on it at once.

There of course is the big point how to process items files before processing the rules which is what all of this thread is about, but what’s the point in introducing a processing order inside the set of rules files?

I don’t think it’s absolutely essential but I do have certain rule files that I consider more low level than others. Maybe generic helpers like item synchronisation, MQTT messaging for group state changes (can’t get the binding to do that for me), alert and debug rules etc so I’d rather load those early on.

Also the likes of Astro rules trigger a lot events in other rules ‘on change’ so why not just ensure it is loaded early updated and then the other startup rules will initialise themselves from the latest value rather than initialise and then change seconds later.

So maybe more preference and optimisation than a requirement :slight_smile:

If anyone is looking for a solution in combination with the official docker-image, you can use a ramdisk (option in docker) and create a custom entrypoint, that copies all files to that ramdisk before the rules above renames them.

I am considering to implement your workaround (alternative 1).
Two question though.

  1. The 240 seconds timer (waiting time) is pretty system depended, I guess.
    So how to know when the system is ready for activating the rules?
  2. I have a “system started” rule to initialize some items during startup in place already.
    WIll this still work?
  1. yes, it is system dependent. Watch your log. You will see. At some time no bindings, things or services are being initialized, it’s just simple item-changes. (Be aware, all changes from NULL to anything are persistence initializing)
  2. you need to put this rule in the moverules.rule file, then it will work. Otherwise not.

Alternative 1 needs one shutdown to become functional.

Alright - thanks a lot.

This is no longer on problem using the current release of OpenHABian

Okay … and what makes you say that ?
(and do you really mean openHABian ? or did you mean to say openHAB?)

Hi,

The version of Linux with the current HABian release is 4.14 - and the command below now works

systemctl edit  openhab2.service

Ok. I misunderstood and thought you were referring to the whole need to setup deferred rules processing. That I believe still applies.

Sorry for the confusion - no that is not fixed :frowning: Its why I am reading on ways to solve this problem.

It seems strange to me to not have addressed this. I spent a fair bit of time trying to understand why rules were not working that had been working before. Reading about the problems on here and github makes me think this should be a priority.

I just wanted to add my voice to this thread. This approach (@ptweety override) worked perfectly and resolved a number of long running issues that sometimes caused instability. Thanks!

I would also like to be able to control the order that rules get loaded. I have some rules that do calculations and update the values of other items. If these rules are not run first, I get errors from other rules that try to do calculations on null values.

This?