Si mvse inició como:
ssh host mv x y
Luego mvrecibirá un SIGPIPE (y morir) si intenta escribir algo en stdout o stderr (como un mensaje de error).
Si comenzó una sesión interactiva como:
ssh host
Y comenzó mvdesde el shell interactivo allí, cuando el lado maestro del pseudo-terminal iniciado sshdse cerrará (al sshcerrar la conexión TCP al salir), el líder de la sesión asociada con el lado esclavo del pseudo-terminal, que es el shell interactivo remoto, recibirá una señal SIGHUP (cuelgue).
Al recibir esa señal, los shells (a menos que haya emitido un trap '' HUP) generalmente envían esa señal a todos los procesos en los trabajos que han comenzado, a menos que le haya dicho explícitamente que no lo haga (como con disowno con &|algunos shells).
Otros procesos (como mv) generalmente morirán al recibir esa señal a menos que se les haya dicho que la ignoren (al usarla nohupo si su padre la ignoró).
Si ha emitido un:
trap '' HUP
Luego, todos los trabajos iniciados después de que lo hereden e ignorarán SIGHUP.
El shell no morirá por la señal SIGHUP enviada después de la desconexión, sino que saldrá en el siguiente mensaje, ya que su stdin se ha ido. Al salir, algunos proyectiles envían SIGHUP a sus trabajos (no rechazados). Los que comiencen después trap '' HUPlo ignorarán, los otros morirán.
En resumen, en ese caso, a menos que haya tomado precauciones previas para que no suceda, mvmorirá.
Para evitarlo la próxima vez, si usa tcsh, zsho bash, antes de apagar la máquina, presione Ctrl-Zpara suspender mv, ingrese bgpara reanudarla en segundo plano y disownpara rechazarla .
O podrías usar screeno tmux. Tras un SIGHUP, esos se desconectarán de su terminal host ahora desaparecida, pero las aplicaciones que se ejecutan en el terminal que emula continuarán ejecutándose sin cabeza y puede volver a conectar la sesión a otro terminal más tarde para ver cómo mvfue.
O use nohup mvpara hacerse mvinmune a SIGHUP y hacer que su salida y errores vayan a un nohup.outarchivo que puede verificar más adelante.
Ahora, no sé acerca de su proveedor de alojamiento específico, pero con algunos, cuando ingresa ssha la instancia, no está iniciando una sesión de shell allí, sino que se conecta a la consola, es decir, a una sesión que ya se inició. , y cuando sale, no termina esa sesión, solo se desconecta de ella. Entonces, el caparazón no mata, ni tampoco mv. Si ese es el caso, notará que psejecutar desde allí le daría lo mismo pidpara su shell en dos sshsesiones separadas .