Not sure if I've observed this just plain not work before, although calling shutdown
in an ssh session may often cause it to hang on your side. I'll hazard a guess and say the reason you have this problem with wifi but not ethernet is because of the bit of latency involved. TBH that's a dubious, unsatisfying guess, but I don't think we need a complete understanding.
The way I deal with shutdown via ssh is to send the command into the background and exit. My personal preference is actually halt -p
but I am not sure if that matters:
sudo halt -p & exit
To explain: &
backgrounds a process, meaning the call returns immediately, before the command itself completes. Shutting down the system usually takes at least a few seconds before the final move, which is to tell the hardware to poweroff (I'm not sure how meaningful that is on the pi -- so the -p
may just be an irrelevant habit).
The exit
then refers to the ssh login, so that will then be immediately disconnected properly. The way the timing works out is that halt
on the other end won't have stopped sshd
yet, so no snags.
Beware:
Using this method (foo & exit
) with most processes will probably end up with the process failing or dying mysteriously. It works with halt
(or shutdown
) because these are actually commands to the init system. Not a complete explanation, but enough said here.
foo & bar
is very different than foo && bar
. The latter means wait for foo
to finish executing and then only start bar
if foo
succeeded. That's not what you want to do.