Greg Norris wrote: > Roberto C. Sanchez wrote: > > I occasionally log into a machine remotely and start a process in the > > background: > > > > command & > > > > However, when I log out of the machine, the ssh process on my local > > machine blocks. > > This is often caused because the process still has a file descriptor (FD) > referencing the tty. Ssh doesn't like to terminate when this occurs, > because there's a chance that the FD could still be required.
Agreed. SSH must keep the connection open in that case. This commonly trips people up. You can use the <newline>~# command to see what connections are still open. You can forcibly terminate the connection with <newline>~. (<newline>~? gives help.) > If this is the case, then you probably just need to redirect the > usual suspects... stdin, stdout, and/or stderr. Something like: > > $ command </dev/null >&0 2>&0 & With BSD job control is it also necessary to disassociate from the controlling terminal. Otherwise the command will still be attached to the tty device as you can see from a ps listing. The 'at now' suggestion previously posted is one common but clever way to launch as a daemon without associating with a tty that avoids the problem. > It may not be necessary to redirect all of them, but that will probably > require some experimentation to determine. You may want to consider > running your command under "nohup" as well, to protect it from the loss > of your session. Before BSD job control the nohup command was sufficient. Just ignore the SIGHUP produced when you logged out and the job would keep running. But with job control kernels nohup is not sufficient. It does redirect input and output and so helps there. But it does not disassociate from the tty. Bob
signature.asc
Description: Digital signature
