Is it possible to put foreground process into background without suspending (control +z)?

Solution 1:

First things first: there can only be one process in the foreground, not all three. fg brings the latest process into foreground. To make the process of Ctrl+z, then typing bg faster to not "disturb" the application in question (note that the process scheduler will do this anyway many times per second), find out the PID of the process in foreground, then in a second terminal/SSH session, use

kill -SIGSTOP »pid« ; kill -SIGCONT »pid«

Your original terminal will say stopped, but since you sent a SIGCONT right away, the process will continue to run in the background.

Solution 2:

If you really have a foreground job, then bash is waiting for it to complete, that's more or less the definition of a foreground job. If bash still has control of the terminal, check what's happening with jobs -l, e.g.:

$ ncat -kl -p 10111 &
[1] 13404
$ ncat -kl -p 10222 &
[2] 13405
$ ncat -kl -p 10333 &
[3] 13406
$ jobs -l
[1]  13404 Running                 ncat -kl -p 10111 &
[2]- 13405 Running                 ncat -kl -p 10222 &
[3]+ 13406 Running                 ncat -kl -p 10333 &

I started three background ncat listening processes for this. You may also see "Done" or "Stopped" for a job status.

You can effectively background a foreground job from a different shell using Stefan Seidel's SIGSTOP/SIGCONT method (though the actual signal sent by a shell with Ctrl-Z is SIGTSTP, either signal should work).

There is a subtle distinction between processes and jobs when the terms foreground and background are used. There is only one shell foreground job, there can be multiple foreground processes (this is related to terminal process group IDs, and can be observed when you start two or more process in a pipeline).

A running processes or pipeline under the control of the shell is referred to as a "job", when you use the bg or fg command you're implicitly referring the most recent job – in my case the one with the + in the above. These jobs can also (amongst other things) be referred to explicitly as %1 %2 or %3 (the number in []).

An unqualified fg command will only affect one job, the most recent, so you may be mistaken in your understanding of the current situation. A background job may still write to the terminal:

  echo foo > /dev/tcp/127.0.0.1/10111

It can depend on how the program handles the terminal, ncat works fine for writing. For reading though programs will stop execution, and you'll see a "Stopped" message. The shell will start processes and wait for them to exit or receive a SIGTTIN signal (nohup is a way around this, as is disown).

You can background a specific stopped job with

$ bg %3

(in my case I will get the error bash: bg: job 3 already in background)

Otherwise if a process is in the foreground, unless the program catches SIGTSTP and does something special, it's unlikely to have problems with a quick Ctrl-Z and bg. There's nothing special about network programs in this respect, incoming connections/data will be buffered by the kernel (up to a point). A streaming connection may have an observable pause though.

See the "JOB CONTROL" section of the bash man page for more details.

Solution 3:

The easiest way for you to do this is to use the screen program. You can start your application within the virtual terminal, then exit the screen with Ctrl+A,D. If you want to resume your session, your type screen -x. If you have multiple processes, you will be presented with a list of screens to reattach to. For more details please read the screen man page.