12

I am moving one directory to another using mv command.

However, I was forced to shut down my computer, which means losing connection to the server.

What happen to the mv command?

Note: After I relogin, I saw that all the files have been properly moved even though I was sure that it wasn't moved when I closed the connection. It seems that mv did continue running.

This is me ssh to centosh machine in steadfast.net cloud server.

user4951
  • 10,519
  • I guess, It will throw an error about unavailability of source/destination – SHW Dec 10 '13 at 07:28
  • 1
    moving a directory to another is "instantaneous" if they are on the same partition. And even if you move files per files, it can be fast. Are you sure it did continue after you disconnected (instead of finishing while the different SIGHUP signals are sent to the child processes, which can take some [at the computer scale] time. – Olivier Dulac Dec 10 '13 at 09:52
  • 1
    as a workaround, use screen or tmux once loggued in to start a virtual terminal that will continue to operate when you disconnect [ie, you can later re-attach to it and see the terminal in the same state as you left it, plus any updates in between] – Olivier Dulac Dec 10 '13 at 10:03

1 Answers1

20

If mv was started as:

ssh host mv x y

Then 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:

ssh host

And started 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 tcsh, zsh or bash, before shutting down the machine, press Ctrl-Z to suspend mv, enter bg to resume it in background, and disown to disown it.

Or you could use screen or 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 mv went.

Or use 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 ssh sessions.

Stéphane Chazelas
  • 544,893