Can't run a shell script via OH

  • Platform information:
    • Hardware: RPi 4
    • OS: Openhabian
    • openHAB version: 3.2

Hi all, I’m trying to do something I thought I know how to do but I guess I’m missing something, and since I’m not a Linux expert I can’t figure it out. Any suggestion would be highly appreciated.

So my OH server is running on a Raspberry Pi with openhabian installation. (Let’s call it Pi1)
I have another Raspberry Pi which I’m trying to control via OH. (Let’s call it Pi2)

I wrote a shell script on Pi2 that restart a certain service, and I want to execute it remotely from Pi1.
The command I’m using is on Pi1 is:

/usr/bin/sshpass -p <my_pass> /usr/bin/ssh pi@Pi2_ip_address '/home/pi/'

When I’m logging in to Pi1 (as user openhabian) and run it, it works and the service is restarting.

Now I want to run it from a rule inside OH.
But it’s a long line with many arguments so I created a script on Pi1 with this exact line so I could just run the script form the rule.
I checked that the script executes correctly from the command line, and inside my rule I added this line:


So to sum it up- I have a script on Pi1 that should remotely execute a script on Pi2.
And the problem is that it’s not executing from the rule.

My guess is that I’m doing something wrong with the file’s permissions.
I know OH runs as user openhab so I tried to following the see if the script will run for user openhab:

sudo -u openhab /usr/bin/pipanel/

And it’s NOT working.
I tried to add execution permissions for all users with chmod and it’s still not working.
I can see that the owner of the file is root.
And I also tried to compare this script to another script I have that I can run successfully from a rule with executeCommandLine but I can’t spot any difference with the permissions or ownership (both are owned by root).

Like I said I’m far from being a Linux expert so any thought about what should I check would be highly appreciated.

Thank you all.

You might first try the standard approaches - see if the OH framework is trying to tell you something, look in your openhab.log

Then see if the script is trying to tell you something - this is for DSL rules, but if you use some other rules language you will need to adapt.

var results = executeCommandLine(Duration.ofSeconds(10), "/usr/bin/pipanel/")
logInfo("test", "exec attempt " + results)

I’d think you are rather asking about the Y part of an XY type of problem.
There should not be a need to restart any part of OH running on Pi2 (let alone the box itself) as OH is supposed to run 24/7, and when there isn’t you don’t need to get this script to work.
I suggest you stop spending time here and go looking after X instead (whatever that is), open another thread if you need help with that.

Right that’s a fair point…

I didn’t mention it but I checked the log file and there’s no alert or any comment.
I also added a logInfo line after the executeCommandLine to make sure that the rule is actually firing and it is.

I didn’t think about this method. Tried it now and results is empty. So no reply from the execution.

@mstormi respectfully, you sometimes have a tendency to explain why the question and the user are wrong, instead of taking the charitable approach.

I’m not running OH on Pi2 and I have several actions I want to run remotely. The restart of a certain service (not OH) is just one example. There are few more actions that behave the same so I just didn’t bother to overload the post with them.

I don’t understand the suggestion. You’re assuming my problem is not the one I’m asking about and telling me to open another thread with the “right” question in your mind?
I’m not trying to be a wise guy here- I’m asking exactly the question I’m trying to solve-
Trying to run a script from OH and can’t seem to make it.

Likely not permissions, then. But as this is all about remote access, does user openhab need permissions on that remote service?

First try just to have only a simple “echo xxx” in your script to check if that output makes it into the “results” var in DSL.

You might need to be wary of timing, as well. Put a log immediately before executeCommandLine() as well as the results log after, and you can see how long it spends in there - as well as see if maybe hitting the timeout.

Ok so I took all the advices above… Thank you so much!

Added an echo line to the script on Pi1 (that OH should execute) and I’m logging it from the rule.
Added a logging line before executeCommandLine so I could check the timing.
And also added an echo line to the script on Pi2 that add the current time stamp to a file on Pi2 so I could verify whether or not the script executes.
And finally tried to execute it in different ways.

  1. Running from a rule- results retuned the echo, took less than a second to run, the script on Pi2 didn’t run at all
  2. Running from command line- echo was ok on Pi1, on Pi2 the script and the echo worked as expected.
  3. Running from command line but with sudo- echo was ok on Pi1, but the script on Pi2 didn’t execute at all.

Is the fact that with sudo the script won’t run gives any clue to the problem?

You’re right, sorry. I might be a little fixated on that but then again this is because there’s many other posts on the forum asking for “how do I restart the box or OH or parts of it via script” which (almost) always is not a good and in fact often even harmful idea and an XY problem, and in those cases the ‘charitable’ approach is right this, i.e. make people aware it’s XY and ask them to go after the real problem.
Don’t be afraid of overloading the explanatory part of a post, it’s right the opposite: being more verbose about this in the first place is always a good idea, it’s minimising chances we misunderstand and helps to avoid waste of time on everybody’s part. Sorry for misreading your post.

No problem! All good. :slightly_smiling_face:

Will do. Thanks for the advice.

This this this. We would much rather have too much information than not enough. And when you are having problems, you may not even know what is relevant or not and end with holding information we need.

Anyway, one key piece of information here

OK, so forget about messing with rules and executeCommandLines or any of that stuff.

Focus on making it work from the command line using sudo -u openhab. It’s never going to work from a rule until it works that way.

It’s not clear though what “not working” really means. Errors? If do we need to see them. Fails silently? We need to be told that explicitly too. If possible we need to find out where in that chain of calls the command is failing. Is it sshpass, ssh or the script on the other machine?

Sometimes ssh will not connect if the certificate on the remote machine changed for some reason. The first time you connect via ssh to a remote machine you also have to accept the certificate. Sop maybe it’s getting hung up asking for an answer that will never come.

So build up to it. To make things easy open a shell as user openhab.

sudo -u openhab /bin/bash

Now try to ssh to the remote machine

 ssh pi@Pi2_ip_address

If that worked now try it with sshpass.

If that worked now try the full command to call

Only when you can get to it working from the command line running as user openhab should you mess with executeCommandLine. It won’t work there until you can make it work from the command line as the openhab user.


Brilliant! Thank you very much for the great suggestions.

That one did it…
When I tried ssh it prompted to trust the device. After accepting the script executed successfully from the rule.

It’s weird though. Since I already logged from Pi1 to Pi2 via ssh and also when I ran the script as the user openhabian it worked. May be the certificate needs to be accepted by every user separately?

Anyway it’s working now, thank you everyone for the valuable advices.
Great community!! :smiley:
Cheers all!!

Right, that was with user openhabian. These certificates have to deal with trust. User openhabian trusts Pi2. But just because user openhabian trusts it doesn’t mean that user openhab must trust it too. Every user maintains their own list of trusted ssh hosts (listed in ~/.ssh/known_hosts). Once trusted, if the machine later presents a different certificate, ssh will refuse to connect and throw up a warning because the remote server has essentially changed it’s identity (or maybe someone is playing man-in-the-middle).

1 Like

For your next challenge think of a way to detect that so that openHAB can signal for some attention needed :wink:

Every day I learn a new thing is a good day! :smiley: