EXEC-Binding errors after update to Openhab2 2.5.2-1

Add-ons Bindings
5

I ran over this error as well and created the exec.whitelist file as documented. But I still get the error message. Am I the only one having this problem? (running linux on an Odroid N2).

6

This helped me:

  1. shutdown openhab
  2. clear caches
  3. reboot server
  4. be patient! It took a little while for openhab to recognise the settings. Suddenly everything worked fine.
    :wink:
7

Nope. I cleared the cache, did shutdowns of the machine, restarts of openHAB, and reloads of the binding but nothing happens. What seems strange to me (after having a look at the source code) is that although I set DEBUG log level for the binding, none of the related error/warning messages show up (e.g. that the whitelist file could not be read).

8

I have created the exec.whitelist file but I also get the “but it is not contained in whitelist” warning messages. I tried several things but I really don’t get it to work.

9

Same here, the exec binding still prints out only error messages. The exec-things are defined in a things-file like this:

Thing exec:command:motioneyestatus [command="ssh root@192.168.178.3 systemctl status motioneye.service | grep 'Active:' | awk -F \" \" '{print $2}'", interval=15, timeout=5, autorun=false]

I’ve added the command in the whitelist file with and without backslashes:

ssh root@192.168.178.3 systemctl status motioneye.service | grep 'Active:' | awk -F " " '{print $2}'
ssh root@192.168.178.3 systemctl status motioneye.service | grep 'Active:' | awk -F \" \" '{print $2}'

Also tried both linux and dos EOL format, restarted openhab, cleared the cache but nothing helps. Even after went back back to version 2.5.1 nothing works. For now I’ve deactivated the things and hoping for a better documentation how to specify commands in the whiltelist


I’m running openhab on a Raspberry Pi 3 with DietPi, manualley installed in /opt/openhab2

10

the thread @helmar74 had already linked above handles the same problem now.
for @rkrisi and me a completely insane way was the solution :crazy_face:
hopefully somebody can identify the exact problem and solution soon


11

Uninstall the 2.5.2 version of the binding and reinstall the 2.5.1 version.

12

Can you tell me how to do this?
Through PaperUI ?

-ben

13

Same for me. I use only a few scripts, but with a big amount of parameters.
I have to add a line for each call? Crazy!

14

I am using OpenHAB 2.5.1 and have this issue and nothing helps so far. How do I downgrade the binding to 2.5.1 as well?

What is the general way to a) downgrade a binding and b) where do I find the corresponding .jar file? I looked at ci.openhab.org but the CI server there didn’t really show me any artifacts I could use.

15

I set logging to trace and found the following line, which stands totally for its own (so no further explanation is given):

2020-02-21 13:31:30.948 [WARN ] [me.core.service.AbstractWatchService] - Cannot read whitelist file, exec binding commands won’t be processed: /home/openhab/conf/misc/exec.whitelist

I have no idea what the reason for inability of reading the file could be. Permissions are set to OpenHAB user and the usual 755 and there’s nothing special about it. When I set permissions to 777 the warning is gone, but the non-executability info still stays.

1 Like
16

I saw the same warning message in the log whenever I copied my amended whitelist file over during my setup of it while OH was running. Even with this warning message the entered whitelist commands did work however.

During a fresh startup of OH this warning didn’t appear for me.

17

It would be nice, if the maintainers could add some debug logging to the process of reading and processing the whitelist, so one can understand what’s going on. In my case, the above warning only means that the whitelist is obviously in the right place but I have no idea what prevents it from being properly processed.

18

Are you sure it’s not being processed properly, since I got the same warning message, but the newly entered whitelist commands were exectuted correctly in spite of the warning - which means the modified whitelist file was recognised and processed.

Have you tried any of the commands after seeing this log warning?

19

Yes - unfortunately and as I wrote in the last sentence of my above comment, the non-executability info still shows up in the logs and the scripts are not being executed.

20

You can uninstall the original through Paper UI, I think. Then you take the 2.5.1 exec binding jar and drop it in the addons directory. After that you should be able to configure it through PaperUI, I think. I haven’t had the chance to try any of this yet


21

Thanks but meanwhile problem is solved:

  • Removed the CRLF in the exec.whitelist file and replaced by LF only;

  • Restarted OpenHab;

Did solved my problem!

22

Hi to all,
the solution with CRLF and LF didn’t wok for me


I wrote this rule:
when
System started
then
executeCommandLine(“chmod -v 775 /etc/openhab2/misc/exec.whitelist”)
end

I found out every time (at startup of my openHAB) when I re-saved the exec.whitelist file the scripts start working until the next start of openhab

It’s only a workaround but I hope I could help a little bit as a newbie :wink:

23

This line ending character(s) behaviour is quite weird.

I had a quick look at the source code and the ExecWhitelistWatchService class uses Files.lines().forEach() which ultimately leads to BufferedReader.readLine().
The readLine method documentation states:
“Reads a line of text. A line is considered to be terminated by any one of a line feed (‘\n’), a carriage return (‘\r’), or a carriage return followed immediately by a linefeed.”
and its result is specified as:
“A String containing the contents of the line, not including any line-termination characters, or null if the end of the stream has been reached”

Also, the Java documentation states the following as valid line termination characters:

  • \u000D followed by \u000A , CARRIAGE RETURN followed by LINE FEED
  • \u000A , LINE FEED
  • \u000D , CARRIAGE RETURN

Could this be a character encoding issue?

Is everyone reporting issues here running on Linux or are there also Windows users?

24

For me it was CRLF. Changed to LF as it should be helpded.
but


after restart it does not work again.