Tag Info

Hot answers tagged

99

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 ...


42

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 ...


38

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 ...


29

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, ...


25

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


21

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 ...


21

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 ...


19

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 ...


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

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"). ...


13

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 ...


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 ...


12

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.


12

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


12

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


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

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 not given and time an 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 ...


8

As maxschlepzig said you could use kill kill -SIGSTOP [pid] and kill -SIGCONT [pid]


7

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 ...


7

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 ...


6

Too late. After a process is started, shell has no more control on process file descriptors so you can not silence it by a shell command. You can only try to kill a SIGHUP to the process. If your process handles it correctly, It should detach from controlling tty. Unluckily, many software do not handle it correctly and simply die.


6

This usually happens if the process tries to read from its stdin stream. When the process is in the background, it receives a TTIN signal and is thus frozen (same behavior as a STOP signal). There is also the dual signal TTOU when a background process tries to write to its terminal. Bringing it to the foreground resumes the process and allows it to read ...


5

You should use kill To be more verbose - you have to specify the right signal: kill -TSTP


5

That should work: are you sure your .bash_aliases is read? (It's not a standard file, but it might be sourced by your ~/.bashrc. If you're confused about .bashrc and .bash_profile, see Difference between .bashrc and .bash_profile.) There's a bug in your function: it should be editorz () { gedit "$@" & disown } Your version doesn't work on file ...


5

screen, tmux, or dtach (possibly with dvtm) are all great for this, but if it's something where you didn't think to use one of those, you may be able to leverage nohup.


5

This is exactly what screen and tmux were created for. You run the shell inside the screen/tmux session, and you can disconnect/reconnect at will. You can also have multiple shell sessions running inside one gnome-terminal.


5

According to the Bash Reference Manual: Job Control: In output pertaining to jobs (e.g., the output of the jobs command), the current job is always flagged with a +', and the previous job with a-'.


5

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 ...


5

Yes, all you need to know is the process id (PID) of the process. You can find this with the ps command, or the pidof command. kill $(pidof ping) Should work from any other shell. If it doesn't, you can use ps and grep for ping.


5

As long as the jobs were all started from your current shell: use 'jobs' to get a list of backgrounded jobs. Each will have a numeric identifier, starting from '1'. Then you can bring the job to the foreground with fg %1, send it to the background if it's paused with bg %1, or kill it with kill %1 (use the correct number for the job you're trying to kill, ...



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