mv was started as:
ssh host mv x y
mv will receive a SIGPIPE (and die) if it tries to write anything to stdout or stderr (like an error message).
If you started an interactive session like:
mv from the interactive shell in there, when the master side of the pseudo-terminal started by
sshd will be closed (upon
ssh closing the TCP connection upon exit), the leader of the session associated with the slave side of the pseudo-terminal, that is the remote interactive shell, will receive a SIGHUP signal (hang up).
Upon receiving that signal, shells (unless you've issued a
trap '' HUP) typically forward that signal to all the processes in the jobs they've started, unless you've explicitly told it not to (like with
disown or with
&| in some shells).
Other processes (like
mv) will typically die when receiving that signal unless they've been told to ignore it (by using
nohup or if their parent ignored it).
If you've issued a:
trap '' HUP
Then all jobs started after it will inherit it and will ignore SIGHUP.
The shell will not die of the SIGHUP signal sent upon the disconnection but will exit at the next prompt, since its stdin is gone. Upon exit, some shells send SIGHUP to their (non-disowned) jobs. Those started after the
trap '' HUP will ignore it, the others will die.
In short, in that case, unless you've taken prior precautions so that it doesn't happen, your
mv will die.
To avoid it next time, if using
bash, before shutting down the machine, press Ctrl-Z to suspend
bg to resume it in background, and
disown to disown it.
Or you could use
tmux. Upon a SIGHUP, those will just detach from their now gone host terminal, but the applications running in the terminal it emulates will continue running headless and you can reattach the session to another terminal later to see how
nohup mv to make
mv immune to SIGHUP and have its output and errors go to a
nohup.out file which you can check later.
Now, I don't know about your specific hosting provider, but with some, when you
ssh into the instance, you're not starting a shell sessions over there but rather attach to the console, that is to a session that has been started already, and when you exit, you do not terminate that session, just detach from it. So, the shell doesn't get kill, nor does
mv. If that's the case, you'll notice that
ps run from there would give you the same
pid for your shell across two separate