Se mv foi iniciado como:
ssh host mv x y
Então mv receberá um SIGPIPE (e morrerá) se tentar escrever alguma coisa no stdout ou stderr (como uma mensagem de erro).
Se você iniciou uma sessão interativa como:
ssh host
E iniciou mv do shell interativo lá, quando o lado mestre do pseudo-terminal iniciado por sshd será fechado (após ssh fechar a conexão TCP na saída), o líder da sessão associado ao lado escravo do pseudo-terminal, que é o shell interativo remoto, receberá um sinal SIGHUP (desligar).
Ao receber esse sinal, os shells (a menos que você tenha emitido um trap '' HUP ) normalmente encaminham esse sinal para todos os processos nos jobs iniciados, a menos que você tenha explicitamente indicado (como com disown ou com &| em alguns shells).
Outros processos (como mv ) normalmente morrerão ao receber o sinal, a menos que tenham sido instruídos a ignorá-lo (usando nohup ou se o pai deles o ignorou).
Se você emitiu um:
trap '' HUP
Em seguida, todos os trabalhos iniciados depois herdarão e ignorarão SIGHUP.
O shell não morrerá do sinal SIGHUP enviado após a desconexão, mas sairá no próximo prompt, já que seu stdin sumiu. Ao sair, alguns shells enviam SIGHUP para seus trabalhos (não renegados). Aqueles iniciados depois que o trap '' HUP irá ignorá-lo, os outros irão morrer.
Em suma, nesse caso, a menos que você tenha tomado precauções prévias para que isso não aconteça, seu mv morrerá.
Para evitar isso da próxima vez, se estiver usando tcsh , zsh ou bash , antes de desligar a máquina, pressione Ctrl-Z para suspender mv , digite bg para retomar em background e disown para rejeitar .
Ou você pode usar screen ou tmux . Em um SIGHUP, eles apenas se desconectarão de seu terminal host, mas os aplicativos em execução no terminal que ele emula continuarão sem execução e você poderá reconectar a sessão a outro terminal posteriormente para ver como mv foi.
Ou use nohup mv para tornar mv imune a SIGHUP e ter sua saída e erros em um arquivo nohup.out , que você pode verificar mais tarde.
Agora, eu não sei sobre o seu provedor de hospedagem específico, mas com alguns, quando você ssh na instância, você não está iniciando sessões de shell por lá, mas anexar a o console, que é para uma sessão que já foi iniciada, e quando você sair, você não terminará essa sessão, apenas desconecte-se dela. Então, o shell não mata, nem mv . Se for esse o caso, você notará que ps executado a partir dali forneceria o mesmo pid para seu shell em duas sessões ssh separadas.