I'm learning Linux. Came upon the idea that a process can be attached to a terminal. What does it mean to attach a process to a terminal (TTY) and why would I want to do it?
closed as unclear what you're asking by Rui F Ribeiro, msp9011, schily, Romeo Ninov, Shadur Aug 10 '18 at 7:30
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
NOTE: For a good primer on job control in Unix I'd direct you to the Wikipedia page on the topic - Job control (Unix).
The phrase, "attached to terminal", is typically what you'll hear when talking about jobs in a shell context. But it does have other meanings. the phrase "attach a process to a terminal" can also mean using a tool such as
lsof to attach to a specific process ID (PID) and list information or monitor it.
I'll discuss both, but to start, I'm going to cover job queues, since I suspect that's the one you're looking for.
Background - job queues
In Unix like operating systems, you'll typically see the concept of jobs. In most Unix like operating systems that I've used they all generally work in a similar fashion. That is, they can be backgrounded and assigned a number in a queue (job queue), and they can be acted on from the context of their number in this job queue.
To put something into the job queue, they typically call this act, backgrounding. When you resume a job that's been backgrounded, you call this foregrounding. The commands to do this are
fg typically. You can also put jobs into the background immediately using the ampersand
& at the end of any command you run.
$ sleep 2 &  19189
Here I'm running a sleep command for 2 seconds and backgrounding it. The output immediately gives you useful info, such as the job queue number (
) and the process ID of the backgrounded job, 19189.
When this job eventually terminates it'll print this type of message in the terminal from where it ran:
$ + Done sleep 2
foreground & background
To act on jobs that have been backgrounded:
$ sleep 20 &  19207 $ fg sleep 20 ^C
Here I've sent a job to the background (
&), then brought it back to the foreground (
fg) and then killed it with the Ctrl+C (
If we had multiple backgrounded jobs:
$ sleep 20 &  19224 $ sleep 20 &  19225 $ sleep 20 &  19226 $ jobs  Running sleep 20 & - Running sleep 20 & + Running sleep 20 &
We can see them with the
jobs command. Notice the little
- next to #3 and #2. If I run the
fg command without specifying a job queue number, I'll get the last job that was put into the job queue (
+). For example:
$ fg sleep 20 ^C $ jobs - Running sleep 20 & + Running sleep 20 &
You can use the job queue numbers to act on the jobs. One such method is to kill them. To refer to a job queue's number, you prefix them with a
% when you want to refer to them with other commands, such as
kill. You can of course
kill multiple all at once, or just one:
$ kill %3 %4 %5 $ jobs  Terminated sleep 20  Terminated sleep 20 - Terminated sleep 20 + Running sleep 20 &
Background attaching to a PID
To attach a process to a terminal could also mean the following. Here's my shell's PID:
$ echo $$ 23543
In another shell I'm running
strace and connecting to this process to see what system calls it's making:
$ strace -p 23543 strace: Process 23543 attached read(0,
NOTE: Here you can see that it's waiting in a
read for commands. That's what terminals/shells do.
Here we can see that I've started to type the command
ls within it, and the shell is echoing this backout to the shell in the form of
write() system calls.
read(0, "l", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], , 8) = 0 write(2, "l", 1) = 1 rt_sigprocmask(SIG_SETMASK, , NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, , 8) = 0 read(0, "s", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], , 8) = 0 write(2, "s", 1) = 1 rt_sigprocmask(SIG_SETMASK, , NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, , 8) = 0 read(0,
This is another form of attaching a process to a terminal.
One of the more obscure references to attaching a process to a terminal could be assumed here as well. This U&L Q&A titled: How to attach terminal to detached process? covers that one in all its forms.
The basic premise with this form of the reference, is that you've taken a backgrounded job, and "disconnected" it from the current shell. You do this using the commands
Once a process has been disowned, you can no longer use the
bg commands to act on it. It's no longer associated to your current shell's PID.
The traditional method for re-acquiring a previously disowned process is to use a tool such as
reptyr, which will re-attach a PID to your existing shell. For example say we start 2 jobs and
$ nohup sleep 200 &  19720 $ nohup sleep 200 &  19721
Still attached to our terminal's job queue, let's
$ jobs - Running nohup sleep 200 & + Running nohup sleep 200 & $ disown -a
Now they're gone:
$ jobs $
They're still listed as being children of our original shell's PID (23543):
$ ps -eaf|grep -E "19720|19721" vagrant 19720 23543 0 18:29 pts/1 00:00:00 sleep 200 vagrant 19721 23543 0 18:29 pts/1 00:00:00 sleep 200
Now if we exit and log back in, we'll see that these processes are now listed as being parents of the main PID, 1:
$ ps -eaf|grep -E "19720|19721" vagrant 19720 1 0 18:29 ? 00:00:00 sleep 200 vagrant 19721 1 0 18:29 ? 00:00:00 sleep 200
These processes were able to do this because we
nohuped them and
disown'ed them. Let's reattach one of them:
$ reptyr -s 19720 [-] Timed out waiting for child stop. ^C
NOTE: In the above, I've reattached PID 19720 to my shell and then killed it via Ctrl+C. We can see it's gone now:
$ ps -eaf|grep -E "19720|19721" vagrant 19721 1 0 18:29 ? 00:00:00 sleep 200