Shutting down openhab, from the openhab interface

That’s not the use case I’m looking for.

It might come handy at some point, yet I doubt it as most of my house is running on many Anel HUT’s, that would be without power when the electricity goes down.

On top the DNS, DHCP, MQTT, WIFI, Switches, Internet would all be down. Openhab would not be able to do much without them anyway.

If I want to keep the house running, I think I’m better of with a tesla powerwall of something similar.
And even in that case, I want to have an option to turn of Openhab in a safe way.

Although I’m teaching my kids to ssh into the openhab server and we co-wrote a manual that explains a lot of technical stuff to do, I still want a non technical person to be able shutdown the software.

The hat I linked will turn of safely your controller if power goes down and turn it on when the power goes up. And this is exactly what you want :slight_smile:

only I’m going to do that so ssh is fine.
In what ever I do, I try people not to depend on me.
A) I’m not always around
B) There will be a moment that I will be dead, the house need to be controllable for my family or whoever buys the house.

except I’m running on Pine64 and not on a raspberry PI. It is something I will look into for some of the raspberry Pi’s I’m running.

hmm, so You have already half of this hat functionalities. As I know, pine64 has battery backup functionalities (battery charger and power management IC). For sure there is already a software to handle the shutdown when ac power is gone.

1 Like

I had no idea that Pine64 has battery functionality, I will look into that.

still I was looking for a way to tell openhab to shut itself down, even without power shutdown.
. The original push came because of the electricity shutdown, yet that feature idea existed before.

Hello yves,

I have implemented a restart (The Pi or OH service as well) as the following way. I don’t know if all steps completely right or necessary, but it works fine for me. :wink:
The main problem was the permission to run some commands (where normally sudo is required) via the OH (e.g. Basic UI).

Here are my steps how to implement the Pi restart via the OH UI:

  • Install Exec Binding via PaperUI
  • Edit the sudoers (sudo visudo -f /etc/sudoers)
    If you want a restart of the Pi you can add this line to the sudoers.
openhab ALL = (root) NOPASSWD: /sbin/reboot 
  • Add an item to one of your item files
Switch	system_PIRESTART_sw	"Restart openHABian Server"	<switch>
  • Add a Switch to one of your sitemap files.
Switch	item=system_PIRESTART_sw	mappings=[ON="Restart my Pi"]
  • Create a rule which will run the command
rule "Restart my Pi"
	Item system_PIRESTART_sw received command
	executeCommandLine("sudo /sbin/reboot", 60000)

I hope I did understand your question correct and this could be helpful for you.



Hi reenblack,

I had been starting on a similar solution with a channel="exec:command:
A rule was indeed the next option.

I have two questions.

A) I don’t feel comfortable about having no need for a password.
Do I understand correctly that with this line, only the reboot does not need a password?

B) I was not looking for a reboot, I was looking for a shutdown.
Is there a similar command for a shutdown?

A) That is correct. I was very happy to see that R.S. only gave sudo permission to the reboot command. If you want to control the OH service then you will need to give it permission to run systemctl. Though I don’t know if there is a way you can limit the permissions to just the openhab2 service. So you might end up having to give the openhab user permission to mess with any system service, not just openHAB’s.

There really isn’t a way to do this with a password. Problem one is the openhab user doesn’t have a password. It is a non-loginable account. You would have to give it the ability to login and then give it a password before that even becomes an option. And if you did, then there really isn’t a way to pass the password to the sudo command safely. No matter how you slice it it will require you to have you openhab user’s password in plain text in your Rules or a .things file or somewhere like that.

B) Yes, its /sbin/shutdown. To control the services you need to give permission on /bin/systemctl. A handy tool on Linux machines is the which command. If you want to see where a command you issue on the command line resides you can use, for example which shutdown and it will return the path to the command.

rich@argus:~   which shutdown

back from vacation I was interested in this idea and decided to give it a go. I had read previously in other threads something like this wasn’t possible and it’s also mentioned at the beginning of this thread.

I read everything here and also the link that was posted at the beginning Openhab default user password

Some reports it is possible, yet it didn’t work for me.

I set up sudoers (sudo visudo) including NOPASSWD.
I have the switch item and in sitemap.
I have the rule and also tried the var result = and logInfo which shows the message about great responsibility and problem about tty etc.
I tried running sudo -u openhab reboot (and other commands allowed in sudoers but I get a password prompt for openhab which indicates NOPASSWD isn’t working.
I tried running the command via a script as suggested in the link above by @NCO but still got the password prompt for openhab.
I have rebooted several times

  1. anyone know why this isn’t working or a step I might have missed?

  2. I know I haven’t posted all the code snippets but am on a mobile device but since the password prompt comes up I think I can remember the sudoers config:

openhab ALL: (root) NOPASSWD: /sbin/reboot, /bin/systemctl, /etc/openhab2/scripts/

as it’s asking for a password when I do sudo -u openhab reboot is there something wrong with that entry?

  1. why is a rule used? why can’t the exec binding be used with a switch to execute the sudo reboot command directly?

  2. is the exec binding really needed with the rule? I had the rules giving me the responsibility and tty message without the exec binding installed so it seems that executecmdline intrinsic to OH and not binding dependant?

  1. All I can guess is that your sudoer’s file is not correct in some way. But it has to be correct enough that you haven’t completely killed your sudo. Maybe you accidentally edited the wrong file?

  2. Yes there is. When you run sudo -u openhab that means you are running this command as your login user, probably openhabian. So sudo is asking you for your openhabian password. To test whether you have sudo set up for openhab correctly use sudo -u openhab sudo reboot. If it is correct then you should only be prompted for one password, your login’s password. If it is incorrect then you will be prompted for two passwords. When you issue the command from OH using executeCommandLine or the Exec binding you don’t need the sudo -u openhab because the command is already running under the openhab user. So it would look like executeCommandLine('sudo reboot')

  3. One can use the exec binding. But often it is easier to debug problems when using a Rule. Also, when using a Rule one can do some other stuff before issuing the command (e.g. sending alerts). One approach is no better than the other really.

  4. executeCommandLine is independent from the Exec binding.

1 Like

1.that’s what I’m thinking but I can’t see anything wrong. I do sudo visudo, then automagically nano opens (instead of vi) and I save the file to some xxxx.tmp . I accepted the defaults of control O control X and the changes are loaded correctly on next sudo visudo.

  1. I wrote sudo -u openhab so I don’t see what you wrote as a correction. If I’m being dumb pls pls be boldly specific. Getting it working is more important to me than saving face!

  2. cool to know, thanks.

  3. again, cool to know, thanks. The exec binding was mentioned as a prerequisite which it seems is not. That unlocks a further understanding.

1 Like

Do not run sudo -u openhab reboot from openHAB.

`executeCommandLine(‘sudo -u openhab reboot’)’ is wrong.

It won’t work. It’s not needed.

You are already openhab so there is no reason to sudo -u to the openhab user.

IF you want to test that the openhab user is configured correctly from the command prompt, use

`sudo -u openhab sudo reboot`

But you will have to enter openhabian’s password when you run this command. If it asks for a second password it means you do not have openhab set up correctly.

Never use sudo -u openhab in ANY openHAB Rules or Exec binding configurations.

I don’t think your problem is that sudoers is missconfigured. I think the problem is you don’t understand how sudo works.

When I log in everything I run is running as my login. Lets say I login in as openhabian. Then the command reboot will be run as user openhabian. That will fail because reboot has to be run as root.

So to reboot the machine as the user openhabian I would run sudo reboot. This will make the reboot command run as the user root. I may or may not need to enter my openhabian password depending on the permissions granted in the sudoers to the openhabian user.

So sudo runs everything after it as the root user. What if I want to run a command as some other user? That is what the -u option is for.

To run a command as the openhab user, I would use sudo -u openhab <command>. I will have to enter the openhabian’s password here because I don’t think you can configure sudo to let you run something as another user without a password.

Now I want to see if the openhab user can run the command sudo reboot without a password. I can’t log in as openhab so I need to change to the openhab user. So, if I take the command above to run a command as another user and replace <command> with sudo reboot I end up with

sudo -u openhab sudo reboot

But like I said, you still need to enter openhabian’s password to run the command sudo reboot as the openhab user. Now, if openhab is configured to run reboot with sudo without a password, then that will be the only password asked for. If you have configured it incorrectly then it will ask for a second password.

tl;dr Never use sudo -u openhab inside openHAB. Only use sudo -u openhab when you are logged into a command prompt as some other user and you want to see what the command will do running as the openhab user. You will always have to enter a password when using sudo -u.

1 Like

mm I’m using openhab with a password when I ssh into the machine.
so my openhab user does have a password (I think)

You are logging in to Linux as the user openhab? Did you do anything to set this up?

Some people do for various reasons.

But by default when using openhabian or an apt-get installed openHAB, the openhab user is configured with /bin/false as its shell and logins disabled.

/bin/false is an executable that doesn’t do anything meaning when you try to log in nothing happens and you get kicked back out. Typically users whose purpose is to only run a service are configured with /bin/false or something similar for the shell because you don’t want attackers to use that as an avenue to access your machine. For example, in some attacks the attacker can break out of the running process and spawn the default shell for the user. If there is no default shell then they can’t do anything.

You can see what shell openhab is configured to use with

cat /etc/passwd | grep openhab


rich@norns:~   cat /etc/passwd | grep openhab
openhab:x:110:114:openhab2 runtime user,,,:/var/lib/openhab2:/bin/false

The field after the last : is the shell that gets run when that user logs in.

Similarly, these service level users typically have logins disabled (i.e. do not have a password). If you look in /etc/shadow you can see whether an account has logins disabled by looking for a * in the second field. If there is a * it means the account login has been disabled. If it has a password you will see the encrypted password there instead.

sudo cat /etc/passwd | grep openhab
rich@norns:~   sudo cat /etc/shadow | grep openhab

Now all of this is in reference to the operating system openhab user. The karaf console also has an openhab user that you can log into using ssh. This brings you to the karaf console where you can issue commands like bundle:list and the like. This user does indeed have a password and by default that password is “habopen”.

I’m using pine64 with an install from the pine64 website that includes openhab.
The user is a diferent user then the karaf user.

In my case the cat gives back /bin/bash


OK, that just means the pine64 install is a slightly non-standard install. Most of the tutorials and postings you see will assume a standard apt-get install so you will have to watch out for little differences like these.

Typically you want to constrain what the users that are running a service can do and you usually don’t want to be doing too many manual operations under those users. I’m surprised the pine64 folks are not using this security best practice.

1 Like

It seems you are using MQTT, so maybe the mqtt-launcher project at could be a match for your use case.

1 Like

re: 2

I see where your confusion exists. I wrote i used sudo -u openhab sudo reboot but neglected to say that it was from the command prompt - not from within openhab, of course. I read the links and related before posting here and it’s even clearly spelled out in the exec binding docs That’s definitely not my problem.

…and at this point I was going to paste in the sudoers line that I only remembered before, when I saw the problem. ‘All’ instead of ‘ALL’ in the first occurrence. ffs. Sometimes code blindness, and I’m sure we’ve all been there. Still, someone might find this helpful in the future: check for uppercase ALL in the sudoers file!

So now the switch works using the rule (I didn’t need the bash script workaround). I’d rather have it work with the binding than having a rule to be checked (are rules less efficient on the system?) . @yves thanks for the question and your persistence on this topic!

No. and even if they were they would not be less efficient enough to be a problem. You pretty much have to go out of your way to have performance problems like this on anything more powerful than an RPi 2.

1 Like