Shell_command to shutdown linux

Can anyone help, I’m running Hass.io (Home Assistant 0.80.3), I’m trying to shut down another raspberry pi (OctoPi).

I Looked at the following post:

So I have the following:
ssh -F /config/.ssh/config -i /config/.ssh/id_rsa [email protected] 'sudo shutdown now -h' 2> /config/command.log

The command works, it shut down my pi… BUT it logs an error in HA:

Error running command: `ssh -F /config/.ssh/config -i /config/.ssh/id_rsa [email protected] 'sudo shutdown now -h' 2> /config/command.log`, return code: 255
NoneType: None

Why do I get this error?

If I look at the /config/command.log file I see the following:

Warning: Permanently added '192.168.1.214' (ECDSA) to the list of known hosts.
Connection to 192.168.1.214 closed by remote host.

Please help.

1 Like

run it on the commandline with the verbose option for ssh and see what the problem is.

So due to my lazyness i ssh into my PI and tell it to do irsend.
This is what i have in my configuration.yaml

tvmute: ssh -i /home/james/.ssh/id_rsa -o StrictHostKeyChecking=no [email protected] 'irsend SEND_ONCE SHARP KEY_MUTE'

I just logged into Hass.io via ssh and then I ran the same command with a verbose (-v) flag.

ssh -v -F /config/.ssh/config -i /config/.ssh/id_rsa [email protected] 'sudo shutdown now -h' 2> /config/command.log

I get no errors and the pi shuts down, as expected. The same thing happens in home assistant BUT it gives a log error (Pi still shuts down). Why will HA give an error?

Have you tried the command without redirecting STDERR to the log file? Everything else you have is fairly standard, but I have never seen anyone redirect errors before.

Well the pi WILL disconnect when you ask it to halt.

I use this to shutdown the OctoPi:

rest_command:
  shutdown_octoprint:
    url: http://octopi.local/api/system/commands/core/shutdown
    method: POST
    headers: 
      X-Api-Key: !secret octoprint_API
6 Likes

I suspect that SSH is passing an exitcode of something other than 0 (0 mean everything was as expected)

in normal processes the SSH should return the exitcode of the command you ran, however the command forces a shutdown and the SSH daemon process is being killed so SSH will be reporting that.

So if you disconnect by logging out you should get exit code 0.

If you disconnect for another reason you will get various codes depending on the reason. Not specifically an error, its just the application explaining why it exited.

if you run echo $? immediately after the ssh ends (as in you cant run any other command between the ssh and the echo or you will get the exit code for that command) you will probably see a value other than 0 and that will pretty sure that will be where HA is taking its cue as to whether the command completed as expected.

Hi @allan, thank for your comment. Yes it receives an Exit status of -1. So what you are saying is HA, is handling the response right. I’m going to try @TheNotSoSmartHome solution as I’m trying to shutdown OctoPi. Just wonder what the solution will be for someone trying to shutdown a linux box. Will you just need to live with the error?

Yes I tried it without the redirection, it error’s in HA. that’s why I added the redirection to try and debug why I get an error if the command seems to be working.

A really simply (if extremely dirty) method would be to combine two commands, something like adding ;echo $? to the end of your existing command, providing HA allows this with how it spawns commands.

ssh -F /config/.ssh/config -i /config/.ssh/id_rsa [email protected] 'sudo shutdown now -h'  ;echo $? 

I say really dirty as that should always return a ‘good’ exit code no matter what, as the echo command should always succeed and so exit with 0.

As with all thing Linux there are loads of ways you can do this, but they all amount to the same thing, making HA believe the command did what you wanted.

What exactly is the problem? The remote pi turns off as instructed doesn’t it? A minor error in your log is no major problem.

I can see the OPs point of view here, as a systems admin I am firmly in the camp that logs where ever possible should be error free, that way if there is an error you know there is something wrong that needs investigating.

Unlike some of the software engineers I work with, who when you are working an incident along side them and are viewing application logs and see screens full of errors scroll by in response to your comments of ‘hmm, that doesn’t look healthy’ reply ‘oh no, that’s a good error, it’s expected’

1 Like

@nickrout , if you do something you do it right, or you don’t do it at all. I’m with @allan on this, if it is an error it means something is wrong and should be fixed, in this case it is a false negative. But if there is a way to avoid it I will sure like to keep my system clean. Yes it work, but now I have a solution that works without any errors.

I understand, but also you need to look at the law of diminishing returns.