Run multiple commands and kill them as one in bash

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 want to have a separate look at the output later, you can pipe the output of each command into tee, which lets you specify a file to mirror the output to.

~$ command1 | tee 1.log & command2 | tee 2.log & command3 | tee 3.log

The output will probably be very messy. To counter that, you could give the output of every command a prefix using sed.

~$ echo 'Output of command 1' | sed -e 's/^/[Command1] /' 
[Command1] Output of command 1

So if we put all of that together we get:

~$ command1 | tee 1.log | sed -e 's/^/[Command1] /' & command2 | tee 2.log | sed -e 's/^/[Command2] /' & command3 | tee 3.log | sed -e 's/^/[Command3] /'
[Command1] Starting command1
[Command2] Starting command2
[Command1] Finished
[Command3] Starting command3

This is a highly idealized version of what you are probably going to see. But its the best I can think of right now.

If you want to stop all of them at once, you can use the build in trap.

~$ trap 'kill %1; kill %2' SIGINT
~$ command1 & command2 & command3

This will execute command1 and command2 in the background and command3 in the foreground, which lets you kill it with Ctrl+C.

When you kill the last process with Ctrl+C the kill %1; kill %2 commands are executed, because we connected their execution with the reception of an INTerupt SIGnal, the thing sent by pressing Ctrl+C.

They respectively kill the 1st and 2nd background process (your command1 and command2). Don't forget to remove the trap, after you're finished with your commands using trap - SIGINT.

Complete monster of a command:

~$ trap 'kill %1; kill %2' SIGINT
~$ command1 | tee 1.log | sed -e 's/^/[Command1] /' & command2 | tee 2.log | sed -e 's/^/[Command2] /' & command3 | tee 3.log | sed -e 's/^/[Command3] /'

You could, of course, have a look at screen. It lets you split your console into as many separate consoles as you want. So you can monitor all commands separately, but at the same time.


You can easily kill a bunch of processes at once if you arrange to run them (and only them) in the same process group.

Linux provides the utility setsid to run a program in a new process group (in a new session, even, but we don't care about that). (This is doable but more complicated without setsid.)

The process group ID (PGID) of a process group is the process ID of the original parent process in the group. To kill all the processes in a process group, pass the negative of the PGID to the kill system call or command. The PGID remains valid even if the original process with this PID dies (though it can be a little confusing).

setsid sh -c 'command1 & command2 & command3' &
pgid=$!
echo "Background tasks are running in process group $pgid, kill with kill -TERM -$pgid"

If you run the processes in the background from a non-interactive shell, then they will all remain in the shell's process group. It's only in interactive shells that background processes run in their own process group. Therefore, if you fork the commands from a non-interactive shell which remains in the foreground, Ctrl+C will kill them all. Use the wait builtin to make the shell wait for all the commands to exit.

sh -c 'command1 & command2 & command3 & wait'
# Press Ctrl+C to kill them all

I'm surprised this isn't here yet, but my favorite way of doing this is to use subshells with background commands. Usage:

(command1 & command2 & command3)

Output is visible from both, all the bash commands and conveniences are still available, and a single Ctrl-c kills them all. I usually use this to start a live-debugging client file server and a backend server at the same time, so I can kill them both easily when I want to.

The way this works is that command1 and command2 are running in the background of a new subshell instance, and command3 is in the foreground of that instance, and the subshell is what first receives the kill signal from a Ctrl-c keypress. It is very much like running a bash script with respect to who owns what process and when background programs get killed.