Hot answers tagged background
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)
If your program is already running you can pause it with Ctrl-Z, pull it into the background with bg and then disown it, like this: $ sleep 1000 ^Z + Stopped sleep 1000 $ bg $ disown $ exit
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  Stopped vim - Stopped bash + Stopped vim 23 fg %3 to send the vim 23 process back to foreground. To suspend the process running in the background, ...
nohup read the man page for nohup usage. nohup is the way it's been done long since before screen, tmux, etc were invented. Example: nohup my_long_running_proc & Runs "my_long_running_proc", and any console (stdout/stderr) messages go into a file called "nohup.out" in the directory from which the command was started.
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 ...
When you close a terminal window, the terminal emulator sends a SIGHUP to the process it is running, your shell. Your shell then forwards that SIGHUP to everything it's running. On your local system, this is the ssh. The ssh then forwards the SIGHUP to what it's running, the remote shell. So your remote shell then sends a SIGHUP to all its processes, your ...
cp a b && mv b c && rm a & is correct. & has lower precedence than &&. In fact & has lower precedence than anything other than ; and newline: & is in the same syntactic category as ;, the difference being that ; runs the command list in the foreground while & runs it in the background. You can test this for ...
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.
There are many ways to go about this. Method #1 - ps You can use the ps command to find the process ID for this process and then use the PID to kill the process. Example $ ps -eaf | grep [w]get saml 1713 1709 0 Dec10 pts/0 00:00:00 wget ... $ kill 1713 Method #2 - pgrep You can also find the process ID using pgrep. Example $ pgrep wget ...
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 ...
You should probably use screen on the remote host, to have a real detached command: ssh root@remoteserver screen -d -m ./script
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 ...
The problem is that you're issuing wait in a subshell: if `wait $!`;then Because wait is a builtin, not a command, it's operating on the subshell, not your current shell. The output that you would see but aren't is: wait: pid 12344 is not a child of this shell ...with a return status of 1. To perform your test you will need to do it without using a ...
It will do nothing as far as I know. The ¬ will just be treated as an argument to the command: $ ls ¬ ls: cannot access ¬: No such file or directory
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 ...
you can put it into parantheses like (cp a b && mv b c && rm a )& to include the whole chain.
Sleep can fail if it is terminated during execution: $ sleep 2 $ echo "$?" 0 $ sleep 2 ^C $ echo "$?" 130 Since sleep is an external executable, it is also conceivable that the fork or exec calls could fail, which would also cause bash to generate an error code >0.
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 ...
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.
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: ...
The easiest way is to run fg to bring it to the foreground: $ help fg fg: fg [job_spec] Move job to the foreground. Place the job identified by JOB_SPEC in the foreground, making it the current job. If JOB_SPEC is not present, the shell's notion of the current job is used. Exit Status: Status of command placed in foreground, or ...
You can use jobs to list the suspended process. Take the example. Start with a process: $ sleep 3000 Then you suspend the process: ^Z + Stopped sleep 3000 You can list the process: $ jobs + Stopped sleep 3000 and bring it back to the foreground: $ fg %1 sleep 3000 The %1 corresponds to the  listed ...
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
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, ...
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 ...
In bash you can use fg to get the job to the foreground and then use Ctrl+C Or list the process in the background with jobs and then do kill %1 (with 1 replaced by the number jobs gave you)
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.
The  2289 after your background command shows it worked, and was indeed put into the background. But the output of your command will still go to the terminal, unless you redirect. Here is the comprehensive way to do that: sudo boblightd >std.txt 2>err.txt & If you want both stdout and stderr to go to the same file: sudo boblightd ...
Use tmux or screen to provide a persistent session environment for the command to run in. Using tmux, this could be accomplished in the following way: Start a new session environment: tmux new -s my-session-name Run your command: longrunningcommand Close your terminal window, SSH session or manually detach from tmux using Ctrl+b, then d Reconnect to your ...
Test it with the command xclock. Open a console, type xclock Close the console. xclock disappears. Now type xclock & xclock still disappears cause it is still a sub-process of your shell. Now type xclock & disown Now xclock is no longer a sub-process of your shell and you can close the console and xclock will keep running. I documented ...
Only top voted, non community-wiki answers of a minimum length are eligible