Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am running an application which receives TCP and UDP packets and therefore cannot be suspended. I intially ran 3 processes of the same application, with different arguments, in background mode using &. When I did only $fg, all three process came into foreground. Now I want to send them to background again but without suspension. How can I do that?

share|improve this question

migrated from May 15 '13 at 7:18

This question came from our site for professional and enthusiast programmers.

Here is a ServerFault topic about moving a running process to a new screen instance ->… – AlanBarber May 15 '13 at 12:25

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.

share|improve this answer
@stefen: your solution is convincing. It will not hurt my processes in any way, assuming that if we suspend process then socket connections established do not break(scheduler switching doesn't not disconnect the socket connection am sure of this). Will debug this and update. Thanks a lot. If – rahul.deshmukhpatil May 16 '13 at 4:20

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.

share|improve this answer
I think he's looking for a solution "after the fact", i.e. the processes are running right now. – Stefan Seidel May 15 '13 at 7:43

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/

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.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .