# commands over network

## h2sammo

Can i give machine 1 an emerge command (for example) from machine 2 (over ssh for example) in a way which will carry out that command even if i close the terminal on machine 2 (or the ssh connection dies) ?

i do this sort of thing a lot lately and i hate that i need to keep th e terminal open on machine 2 until the slower machine 1 finished the compilation

----------

## TJNII

Look into the screen utility.  You'll be glad you did.

----------

## h2sammo

how do i do that>

----------

## TJNII

http://www.gnu.org/software/screen/

 *Quote:*   

> Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. Each virtual terminal provides the functions of the DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g., insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows the user to move text regions between windows. When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill the current window, view a list of the active windows, turn output logging on and off, copy text between windows, view the scrollback history, switch between windows, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the users terminal.

 

It is in portage.  See the man page after you emerge it.

----------

## h2sammo

thank you. i dont think however this fits the bill.

what i want is to log into machine 1 from machine 2, start a process (emerge pymol) and then close the ssh connection between the two without losing the process i just started.

----------

## TJNII

Log into machine 1

start screen

start the emerge within screen

detach screen

log out of 1

emerge continues to run within screen.  You can reattach later to check on it, log output, and do other handy things.

----------

## h2sammo

thank you, works like a charm  :Smile: 

now i can compile in the background of the movies my family watches with nice/renice and htop and do it like a pro.

----------

## 1clue

A much simpler arrangement would be "nohup."

ssh yourbox

nohup emerge ... > emerge.log 2>&1

exit

When you log in next time, tail the log to find out if the process is done, or look at ps output.

----------

## h2sammo

so, if i ssh and type

```
nohub emerge htop &
```

 it will allow me to type 

```
exit
```

 after it, and the process will run in the background. i can then interrupt the ssh connection and later on check the emerge logs in /var/log/portage/elog as i wish?

i am not sure the alternative "ps" output you gave me. how do i do that?

----------

## TJNII

Nice thing about screen, though, is you still retain full control of your processes when you detach from them.  If you nohup them into the background you have no means to control them.

----------

## 1clue

@TJNII,

I've rarely even wanted to control the processes afterward.  They work or not, and if they hang I can always kill it later.  Screen is valid and works great if you need/want that sort of thing, but nohup is pretty much guaranteed to be in any UN*X afaik.

@h2sammo,

Nohup is a command that intercepts "hangup" signals.  Pretty simple, either nohup --help or man nohup will give you a simple page of the few options.

When you log out, the system sends a HUP to everything running under that shell.  "nohup" simply prevents that signal from reaching the command that follows it.

Whatever htop puts in the log will still be in that log, but stdout, stderr and such will go to nohup.out if you don't pipe it to something else.  I generally try to make it be something descriptive in case I don't get back to it for awhile.

ps axf | grep htop

----------

