Tag Info

Hot answers tagged

54

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)


28

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.


22

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


20

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


19

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


18

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.


15

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


14

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


13

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


13

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


12

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


12

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.


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

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


10

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


10

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


10

You can use jobs to list the suspended process. Take the example. Start with a process: $ sleep 3000 Then you suspend the process: ^Z [1]+ Stopped sleep 3000 You can list the process: $ jobs [1]+ Stopped sleep 3000 and bring it back to the foreground: $ fg %1 sleep 3000 The %1 corresponds to the [1] listed ...


9

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


9

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


8

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.


8

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


8

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


8

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


8

When they're running Seems like you can just do this with kill and the output of jobs -p. Example $ sleep 1000 & [1] 21952 $ sleep 1000 & [2] 21956 $ sleep 1000 & [3] 21960 Now I have 3 fake jobs running. $ jobs [1] Running sleep 1000 & [2]- Running sleep 1000 & [3]+ Running sleep ...


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

Remove the backticks. As is, you're executing wait in a subshell, which doesn't have access to the parent shell's jobs, so it will immediately fail. If you want the exit status, get the value of $? immediately after the wait. command_here & wait status=$?


7

The [1] 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 ...


7

You can use the command wait PID to wait for a process to end. You can also retrieve the PID of the last command with $! In your case, something like this: command1 & #run command1 in background PID=$! #catch the last PID, here from command1 command2 #run command2 while command1 is running in background wait PID #wait for command1, in background, to ...


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


6

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



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