Hot answers tagged background
29
One of the following 2 should work:
$ nohup redshift &
or
$ redshift &
$ disown
See the following for a bit more information on how this works:
man nohup
help disown
Difference between nohup, disown and & (be sure to read the comments too)
15
What's the difference between running a program as a daemon and forking it into background with '&'?
The traditional way of daemonizing is:
fork()
setsid()
close(0) /* and /dev/null as fd 0, 1 and 2 */
close(1)
close(2)
fork()
This ensures that the process is no longer in the same process group as the terminal and thus won't be killed together with it. The IO redirection is to make output not appear on the terminal.
14
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, ...
14
I don't think you're going to get any more elegant than the
tail -f /dev/null
that you already suggested (assuming this uses inotify internally, there should be no polling or wakeups, so other than being odd looking, it should be sufficient).
You need a utility that will run indefinitely, will keep its stdout open, but won't actually write anything to ...
14
What's the difference between running a program as a daemon and forking it into background with '&'?
For a daemon, what you want is a process that has no tie to anything. At the very least, you want it to be in its own session, not be attached to a terminal, not have any file descriptor inherited from the parent open to anything, not have a parent caring for you (other than init) have the current directory in / so as not to prevent a umount...
To detach ...
11
You can background a task by adding a & after it.
For instance tail -f /var/log/messages & will background the task immediately.
As always you can see what tasks you backgrounded with the jobs command.
This of course assumes you have not yet run the command.
10
Close, but not exactly.
Independently of any terminal
ssh root@remoteserver '/root/backup.sh </dev/null >/var/log/root-backup.log 2>&1 &'
You need to close all file descriptors that are connected to the ssh socket, because the ssh session won't close as long as some remote process has the socket open. If you aren't interested in the ...
10
Put \j in your prompt. From the bash manual:
\j
The number of jobs currently managed by the shell
Just remember that prompts do go stale and jobs can finish at any time, so if you have left the terminal idle, you'll want to redisplay the prompt.
At the cost of requiring an extra process just to print your prompt, you can make the \j only ...
8
If you are using bash, you can set the IGNOREEOF shell variable to a number that specifies how many consecutive EOF chars the shell should ignore before treating the EOF as an exit signal. Check the man page for specifics.
However, that triggers before the "there are stopped jobs" message triggers, so you still have the same problem - you get that message, ...
8
The purpose of watch is to show the results of a command full-screen and update continuously; if you're redirecting the output into a file and backgrounding it there's really no reason to use watch in the first place.
If you want to just run a command over and over again with a delay (watch waits two seconds by default), you can use something like this:
...
8
There are several ways a process might be killed because of a dying terminal.
The first way is that the terminal driver in the kernel sends a SIGHUP signal to the controlling process for which the terminal is the controlling terminal. In most cases, the controlling process is the shell that is initially started in the terminal, and its controlling terminal ...
6
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 ...
6
sleep 2147483647 | program > output &
Yes, 2^31-1 is a finite number, and it won't run forever, but I'll give you $1000 when the sleep finally times out. (Hint: one of us will be dead by then.)
no temporary files; check.
no busy-waiting or periodic wakeups; check
no exotic utilities; check.
as short as possible. Okay, it could be shorter.
5
You can simply nohup the program you are starting and put it in the background akin to:
nohup someShellScript.sh > nohup.out 2>&1 &
EDIT as per Thor's suggestion
From non-interactive session:
ssh <hostname> "nohup someShellScript.sh > nohup.out 2>&1 &"
5
Short answer - no.
Long answer: You are actually calling a python interpreter. That interpreter loads the script.py and parses it.
If you change the script it has to reload the file and start from the beginning, since the interpreter has no way to know which part was changed.
Now if your goal is to simply signal python to reload/restart the script, you ...
5
Sounds like it's reading from standard input (stdin). Try adding the -d (Do not attempt to read from stdin) option to netcat. Or redirect on the command line:
netcat localhost 1099 <&- | bash loop.sh &
You may also want to use nohup to make sure that it won't be adversely affected when/if you exit that shell before it stops.
5
You can run the process like this in the terminal
setsid process
This will run the program in a new session.
As explained http://hanoo.org/index.php?article=run-program-in-new-session-linux
5
It's quite simple to test this. With -e:
% bash -e -c 'false & echo waiting; if wait $!; then echo success; else echo failure; fi'
waiting
failure
So if a backgrounded command fails, the shell will not exit automatically (-e is not enough).
If you wait outside an explicit test, wait will return the return code of the failed backgrounded process. In ...
5
What's the difference between running a program as a daemon and forking it into background with '&'?
With command & Your process will be killed by a SIGHUP signal when the parent dies.
Sysadmins have access to some workaround, though.
On a bash system, you can use:
(trap '' HUP; command) &
This opens a subshell, traps the HUP signal with an empty handler and ampersand/forks it.
Output might still get redirected to the wrong tty. Or get lost.
...
5
Yes, as required by POSIX, commands started in background with & have their standard input redirected from /dev/null.
And indeed
{ cmd <&3 3<&- & } 3<&0
is the most obvious way to work around it.
It's not clear why you'd want to run part of pipeline in background though.
4
Good answer is already posted by @StevenD, yet I think this might clarify it a bit more.
The reason that the process is killed on termination of the terminal is that the process you start is a child process of the terminal. Once you close the terminal, this will kill these child processes as well. You can see the process tree with pstree, for example when ...
4
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 ...
3
You can remember the PID of each new child (check $! after starting it). Periodically check how many children still exist (e.g. by kill -0), if the number goes down, spawn a new one, etc. At the end, just wait.
Here is a script I wrote for the same reason:
#! /bin/bash
## Tries to run commands in parallel. Commands are read from STDIN one
## per line, or ...
3
Check out GNU Screen. You can run something in the screen, then detach and disconnect and the script/program continues to run.
Link: http://www.gnu.org/software/screen/
Screen can be found in most distros. Ubuntu has a forked "Super" version of it available as well.
3
The netcat process is reading from its standard input. Since it's connected to the terminal, the process group that netcat is in (i.e. the pipeline) must run in the foreground.
You need to plug something at the beginning of the pipeline that will send the input that the server expects. For example, with an HTTP server, you might have something like
netcat ...
3
You can use something like:
#!/bin/bash
ex_bg=$(gsettings get org.gnome.desktop.background picture-uri)
str=$(shuf -n1 list)
convert -background black -fill white -pointsize 72 label:"$str" /tmp/new_bg.jpg
gsettings set org.gnome.desktop.background picture-uri "file:///tmp/new_bg.jpg"
sleep 20
gsettings set org.gnome.desktop.background picture-uri "$ex_bg"
...
3
There are at least two way to do that
1) nohup command as already mentioned. Wikipedia has an article about nohup
2) There are two popular terminal multiplexers screen and tmux They enable a number of terminals, each running a separate program. There are a lot of tutorials and how-to about both tools on the Internet, just google
3
What's the difference between running a program as a daemon and forking it into background with '&'?
The difference between running a program/process as a daemon and forking it to the background using the ampersand is basically related to ownership.
Most often, the parent process of a daemon is the init process (the very first process to be started on a Unix system), the daemon being a child of that process means that it is not under your direct control as ...
3
You can use gconftool-2 - GNOME configuration tool. First, you can list all your gnome profiles with:
$ gconftool-2 --get /apps/gnome-terminal/global/profile_list
[Default,Profile0]
Now you can print values for selected profile:
$ gconftool-2 -a "/apps/gnome-terminal/profiles/Default"
Store value of foreground and background color:
$ gconftool-2 ...
3
Your script should check that there is only one instance. Try something like this:
#!/bin/bash
mkdir ~/.lock_script || exit
trap "rmdir ~/.lock_script" EXIT
while true
do
# Do whatever the script does continuously, here....
#
done
The trap command takes care of cleaning up on exit, so even if the script is killed or terminated, it will clean ...
Only top voted, non community-wiki answers of a minimum length are eligible
