Is there a shutdown rule tirgger available to rename it back at shutdown?
rule "rename rules at shut down"
when
something like
System stopped
then
I don’t think renaming at shutdown would help. The underlying issues seem to be around threads and queuing at startup; the renaming trick makes system read the files again after the startup chaos has calmed done a bit?
Works fine for me. Thanks! I, too, have been wanting to implement that for ages, have just been to lazy. Sorry 
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 
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
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 
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.
- 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? - I have a “system started” rule to initialize some items during startup in place already.
WIll this still work?
- 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)
- 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.