341

The PID of the last executed command is in the $! shell variable: my-app & echo $!


256

There are many ways to go about this. Method #1 - ps You can use the ps command to find the process ID for this process and then use the PID to kill the process. Example $ ps -eaf | grep [w]get saml 1713 1709 0 Dec10 pts/0 00:00:00 wget ... $ kill 1713 Method #2 - pgrep You can also find the process ID using pgrep. Example $ pgrep wget ...


216

As Tim said, type fg to bring the last process back to foreground. If you have more than one process running in the background, do this: $ jobs [1] Stopped vim [2]- Stopped bash [3]+ Stopped vim 23 fg %3 to bring the vim 23 process back to foreground. To suspend the process running in the background, ...


153

Before running the command, you can append & to the command line to run in the background: long-running-command & After starting a command, you can press CtrlZ to suspend it, and then bg to put it in the background: long-running-command [Ctrl+Z] bg


113

This is the favorite of all since apart of sending the process into the background you don't have to worry about the text output dirtying your terminal: nohup command & This not only runs the process in background, also generates a log (called nohup.out in the current directory, if that's not possible, your home directory) and if you close/logout the ...


90

The easiest way is to run fg to bring it to the foreground: $ help fg fg: fg [job_spec] Move job to the foreground. Place the job identified by JOB_SPEC in the foreground, making it the current job. If JOB_SPEC is not present, the shell's notion of the current job is used. Exit Status: Status of command placed in foreground, or ...


78

I don't think you're going to get any more elegant than the tail -f /dev/null that you already suggested (assuming this uses inotify internally, there should be no polling or wakeups, so other than being odd looking, it should be sufficient). You need a utility that will run indefinitely, will keep its stdout open, but won't actually write anything to ...


71

In bash you can use fg to get the job to the foreground and then use Ctrl+C Or list the process in the background with jobs and then do kill %1 (with 1 replaced by the number jobs gave you)


68

To run commands concurrently you can use the & command separator. ~$ command1 & command2 & command3 This will start command1, then runs it in the background. The same with command2. Then it starts command3 normally. The output of all commands will be garbled together, but if that is not a problem for you, that would be the solution. If you ...


67

Get PID: #!/bin/bash my-app & echo $! Save PID in variable: #!/bin/bash my-app & export APP_PID=$! Save all instances PID in text file: #!/bin/bash my-app & echo $! >>/tmp/my-app.pid Save output, errors and PID in separated files: #!/bin/bash my-app >/tmp/my-app.log 2>/tmp/my-app.error.log & echo $! >>/tmp/my-app.pid ...


64

An especially good solution for scripting is to use master mode, with a socket for control commands: ssh -f -N -M -S <path-to-socket> -L <port>:<host>:<port> <server> To close it again: ssh -S <path-to-socket> -O exit <server> This avoids both grepping for process ids and any timing issues that might be ...


52

Close, but not exactly. Independently of any terminal ssh root@remoteserver '/root/backup.sh </dev/null >/var/log/root-backup.log 2>&1 &' You need to close all file descriptors that are connected to the ssh socket, because the ssh session won't close as long as some remote process has the socket open. If you aren't interested in the ...


51

When you close a terminal window, the terminal emulator sends a SIGHUP to the process it is running, your shell. Your shell then forwards that SIGHUP to everything it's running. On your local system, this is the ssh. The ssh then forwards the SIGHUP to what it's running, the remote shell. So your remote shell then sends a SIGHUP to all its processes, your ...


48

sleep infinity is the clearest solution I know of. You can use infinity because sleep accepts a floating point number*, which may be decimal, hexadecimal, infinity, or NaN, according to man strtod. * This isn't part of the POSIX standard, so isn't as portable as tail -f /dev/null. However, it is supported in GNU coreutils (Linux) and BSD (used on Mac) (...


48

You can use jobs to list the suspended process. Take the example. Start with a process: $ sleep 3000 Then you suspend the process: ^Z [1]+ Stopped sleep 3000 You can list the process: $ jobs [1]+ Stopped sleep 3000 and bring it back to the foreground: $ fg %1 sleep 3000 The %1 corresponds to the [1] listed with ...


47

You should probably use screen on the remote host, to have a real detached command: ssh root@remoteserver screen -d -m ./script


45

Good answer is already posted by @StevenD, yet I think this might clarify it a bit more. The reason that the process is killed on termination of the terminal is that the process you start is a child process of the terminal. Once you close the terminal, this will kill these child processes as well. You can see the process tree with pstree, for example when ...


45

Putting multiple jobs in the background is a good way of using the multiple cores of a single machine. parallel however, allows you to spread jobs across multiple servers of your network. From man parallel: GNU parallel is a shell tool for executing jobs in parallel using one or more computers. The typical input is a list of files, a list of ...


41

I found the solution here: http://www.g-loaded.eu/2006/11/24/auto-closing-ssh-tunnels/ The best way – Tunnels that auto-close As it has been mentioned previously, instead of using the -f -N switch combination, we can just use -f alone, but also execute a command on the remote machine. But, which command should be executed, since we only need to initialize ...


37

It sounds like you want the -N option to ssh. -N Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only).


33

If you have a copy of xargs that supports parallel execution with -P, you can simply do printf '%s\0' *.png | xargs -0 -I {} -P 4 ./pngout -s0 {} R{} For other ideas, the Wooledge Bash wiki has a section in the Process Management article describing exactly what you want.


33

For a daemon, what you want is a process that has no tie to anything. At the very least, you want it to be in its own session, not be attached to a terminal, not have any file descriptor inherited from the parent open to anything, not have a parent caring for you (other than init) have the current directory in / so as not to prevent a umount... To detach ...


32

This is probably what you want my_command > output.log 2>&1 & this will start your command, redirecting both stdout and stderr to some output.log which you can specify. If you don't care to store the output at all - you can use /dev/null instead of an actual file. & will execute command in the background so that you can continue ...


31

This should be true of any shell with job control, which (for the most part) you can take for granted unless dealing with a truly ancient shell. It's in the POSIX standard, so even dash supports job control (when run interactively or with -m). Interactive Ctrl+z will suspend the currently foregrounded program bg will background the most recently suspended ...


31

The traditional way of daemonizing is: fork() setsid() close(0) /* and /dev/null as fd 0, 1 and 2 */ close(1) close(2) fork() This ensures that the process is no longer in the same process group as the terminal and thus won't be killed together with it. The IO redirection is to make output not appear on the terminal.


29

nohup read the man page for nohup usage. nohup is the way it's been done long since before screen, tmux, etc were invented. Example: nohup my_long_running_proc & Runs "my_long_running_proc", and any console (stdout/stderr) messages go into a file called "nohup.out" in the directory from which the command was started.


29

The first system to support multiple concurrently-executing processes, or at least to simulate the concurrent execution of multiple processes, was the Atlas system developed at Manchester University in the UK in the early sixties. The reference for that is the paper describing the system, The Atlas supervisor, written by Tom Kilburn, R. Bruce Payne, and ...


28

#!/bin/bash command1 & command2 & command3 & wait command4 wait (without any arguments) will wait until all the backgrounded processes have exited. The complete description of wait in the bash manual: wait [-n] [n ...] Wait for each specified child process and return its termination status. Each n may be a process ID ...


28

Unless I'm misunderstanding your question, it can simply be achieved with this short script: #!/bin/bash process_a & sleep x process_b (and add an extra wait at the end if you want your script to wait for process_a to finish before exiting). You can even do this as an one-liner, without the need for a script (as suggested by @BaardKopperud): ...


27

You can run the process like this in the terminal setsid process This will run the program in a new session. As explained http://hanoo.org/index.php?article=run-program-in-new-session-linux


Only top voted, non community-wiki answers of a minimum length are eligible