OK.
You see that the systemctl restart openhab2.service, is not causing the problem.
Now the systemctl status openhab2.service is not showing the warning.
But somehow your file /etc/systemd/system/openhab2.service.d/override.conf is changed.
The file /etc/systemd/system/openhab2.service.d/override.conf was changed today “Nov 4 15:06”. You do not happen to know what happened at that point of time?
All done I think. Was editing the results as you posted… I needed sudo for some of the commands…
The file /etc/systemd/system/openhab2.service.d/override.conf was changed today “Nov 4 15:06”. You do not happen to know what happened at that point of time?
I updated OH today to the latest 2.5.10 using openhabian-config and it was after that I saw the error and came here
Updates gave me a fright. log file filled up and filled up. Stopped openhab and the log was still filling up. Had to close browser. I restarted and had to go through the same cycle a few times until it final seemed to start up normally … Its not for the faint hearted.
Hello Mark,
OK. Then this is a problem with the update.
The update should trigger a systemctl daemon-reload before the systemctl restart (or start) openhab2.service
The resulting issue is, that the content of the drop-in file is not considered for the current life-cycle of OH.
As this is “only” a start-up improvement, nothing bad happens, but it should be solved.
I will create a bug.
Thanks for the quick support 
Is it possible that this behaviour is triggered by the script loading optimisation setting in openhabian-config (menu item 40 > sub item 44)?
I have it enabled (I think it is enabled by default nowadays on Raspberry Pi) and I see this behaviour whenever I restart openHAB2…
Hello @shutterfreak,
yes you are right. I ran sudo openhabian-config – 40 – 44 and the drop-in file was changed.
Nov 4 21:36 /etc/systemd/system/openhab2.service.d/override.conf
If this is done the first time - without a later sudo systemctl daemon-reload systemd will - fully correctly give this warning. The configuration of openhab2.service, is indeed changed.
So it appears that openHAB should invoke systemctl daemon-reload to whenever openHAB is (re)started…
No. Only when systemd configuration files are changed i.e. on openHAB up- & downgrades and other components to affect its config files.
I have added that to the code for the aforementioned ‘delayed rules processing’ option 44 (or 45 which it is now) so there should be no instance left where this isn’t done.