Hot answers tagged

162

Let's first look at what happens if a program is started from an interactive shell (connected to a terminal) without & (and without any redirection). So let's assume you've just typed foo: The process running foo is created. The process inherits stdin, stdout, and stderr from the shell. Therefore it is also connected to the same terminal. If the shell ...


132

Using & causes the program to run in the background, so you'll get a new shell prompt instead of blocking until the program ends. nohup and disown are largely unrelated; they suppress SIGHUP (hangup) signals so the program isn't automatically killed when the controlling terminal is closed. nohup does this when the job first begins. If you don't nohup a ...


78

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 send the vim 23 process back to foreground. To suspend the process running in the background, ...


76

You can revoke “ownership” of the program from the shell with the disown built-in: # press Ctrl+Z to suspend the program bg disown However this only tells the shell not to send a SIGHUP signal to the program when the shell exits. The program will retain any connection it has with the terminal, usually as standard input, output and error streams. There is ...


66

Using GNU screen is your best bet. Start screen running when you first login - I run screen -D -R, run your command, and either disconnect or suspend it with CTRL-Z and then disconnect from screen by pressing CTRL-A then D. When you login to the machine again, reconnect by running screen -D -R. You will be in the same shell as before. You can run jobs to ...


57

As maxschlepzig said you could use kill For a 'polite' end to the process (prefer this for normal use), sent SIGTSTP: kill -TSTP [pid] For a 'hard' kill, sent SIGSTOP: kill -STOP [pid] Note that if the process you are trying to stop by PID is in your shell's job table, it may remain visible there, but terminated, until the process is fg'd again. To ...


45

To move a process between terminals or to reattach a disowned, you can use e.g. reptyr.


29

A process is any running program with its own address space. A job is a concept used by the shell - any program you interactively start that doesn't detach (ie, not a daemon) is a job. If you're running an interactive program, you can press CtrlZ to suspend it. Then you can start it back in the foreground (using fg) or in the background (using bg). While ...


26

If some-boring-process is running in your current bash session: halt it with ctrl-z to give you the bash prompt put it in the background with bg note the job number, or use the jobs command detach the process from this bash session with disown -h %1 (substitute the actual job number there). That doesn't do anything to redirect the output -- you have to ...


25

My favorite solution is using tmux, you could detach the session, and re-attach it in another terminal. When you detached from previous session, you can safely close the terminal; later use tmux attach to get back to the session, even if you logged out.


23

UNIX has separate concepts "process", "process group", and "session". Each shell you get at login becomes the leader of its own new session and process group, and sets the controlling process group of the terminal to itself. The shell creates a process group within the current session for each "job" it launches, and places each process it starts into the ...


20

I think you may be confused about the job control notation. Notably "Stopped" means that a job is still alive but that its ability to process anything has been held (it is not given any time on the CPU to process anything). This is effectively a 'Pause' or 'Suspended' state, although that is not the correct technical term. CtrlC does not "stop" a job, it ...


18

There's also a small utility called retty that lets you reattach running programs to another terminal.


17

I don't use it regularly, but neercs claims to support this. It's a screen-like program with miscellaneous fancy features like better pane management, but the main thing it offers is the ability to import a process into a pane


17

The term you are looking for is called "backgrounding" a job. When you run a command either in your shell or in a script you can add a flag at the end to send it to the background and continue running new commands or the rest of the script. In most shells including sh, this is the & character. #!/bin/sh gedit & rm ./*.temp That way, the shell ...


15

Shell jobs live in "process groups"; look at the PGRP column in extended ps output. These are used both for job control and to determine who "owns" a terminal (real or pty). POSIX (taken from System V) uses a negative process ID to indicate a process group, since the process group is identified by the first process in the group ("process group leader"). ...


15

The command does not hang. You think that the command is hanging because you don't see the prompt. The prompt is there. You don't see the prompt because it was pushed up by the output of the background process. Pressing enter after the long output of a background process causes the shell to "execute" the empty line and print a new prompt. Try the following ...


14

You should use the kill command for that. To be more verbose - you have to specify the right signal, i.e. $ kill -TSTP $PID_OF_PROCESS for suspending the process and $ kill -CONT $PID_OF_PROCESS for resuming it.


13

Your kill command is backwards. Like many UNIX commands, options that start with a minus must come first, before other arguments. If you write kill -INT 0 it sees the -INT as an option, and sends SIGINT to 0 (0 is a special number meaning all processes in the current process group). But if you write kill 0 -INT it sees the 0, decides there's no more ...


13

You use bg normally to run programs in the background, which has no console interaction, like most program with a graphical user interface. Example: You wanted to run xterm & but forgot the & to run the terminal emulator in the background. So you stop the (blocking) foreground xterm process with Ctrl-Z and continue it in the background with bg. If ...


9

Your background job continues executing until someone tells it to stop by sending it a signal. There are several ways it might die: When the terminal goes away for any reason, it sends a HUP signal (“hangup”, as in modem hangup) to the shell running inside it (more precisely, to the controlling process) and to the process in the foreground process group. A ...


9

If you've already started something somewhere, backgrounded it, and now need to attach it to a new terminal, you can use reptyr to re-attach it. (The man page summarises the command as "Reparent a running program to a new terminal".) The reason you can't see it in the "jobs" command or use "fg" to bring it to the foreground is because these commands are ...


9

The fact that a process is "disowned" has only a meaning for the interactive shell that created this process. It means that the shell doesn't include (anymore) the process in its jobs table, and that SIGHUP will not be sent to this process when the shell exits. It is not really related with your questions. About what happens to the outputs that are sent to ...


9

Signals are blocked for suspended processes. In a terminal: $ yes ... y y ^Zy [1]+ Stopped yes In a second terminal: $ killall yes In the first terminal: $ jobs [1]+ Stopped yes $ fg yes Terminated However SIGKILL can't be blocked. Doing the same thing with killall -9 yes from the second terminal immediately ...


8

Adding a detail to Anthon's explanation: It is not always the case that a writing background process is stopped. This depends on the terminal setting tostop. stty tostop stty -tostop can be used to toggle this setting. So if you want a background process to write to "another process's" terminal then you can keep it running but don't need tmux, screen or ...


8

I don't think you can reserve or assign PIDs. However, you could start your process in a script like this: myprocess & echo "$!" > /tmp/myprocess.pid This creates a "pid file", as some other people have referred to it. You can then fetch that in bash with, e.g., $(</tmp/myprocess.pid) or $(cat /tmp/myprocess.pid). Just beware when you do this ...


8

After a process is sent to the background with &, its PID can be retrieved from the variable $!. The job IDs can be displayed using the jobs command, the -l switch displays the PID as well. $ sleep 42 & [1] 5260 $ echo $! 5260 $ jobs -l [1] - 5260 running sleep 42 Some kill implementations allow killing by job ID instead of PID. But a ...


8

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). I'm not sure about Bourne (/bin/bsh) or jsh (Solaris's non-POSIX-compliant /bin/sh) support (though iirc, the "j" ...


7

Unfortunately, commands started in background are set by the shell to ignore SIGINT, and worse, they can't un-ignore it with trap. Otherwise, all you'd have to do is (trap - INT; exec process1) & (trap - INT; exec process2) & trap '' INT wait Because process1 and process2 would get the SIGINT when you press Ctrl-C since they're part of the same ...


7

"injcode" from ThomasHabets seems to be exactly the thing I need: https://github.com/ThomasHabets/injcode The injcode program allows arbitrary code to be injected into a running process, whether or not you knew beforehand and were running screen or tmux From the README: Example 1: move irssi from one terminal to another Maybe move it into a ...



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