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 ...
GNU coreutils nohup man page indicates that you can use normal redirection:
If standard input is a terminal, redirect it from /dev/null. If standard output is a terminal, append output to 'nohup.out' if possible, '$HOME/nohup.out' otherwise. If standard error is a terminal, redirect it to standard output. To save output to FILE, use 'nohup COMMAND > FILE'....
What's better, a fish or a bicycle? nohup and exec do different things.
exec replaces the shell with another program. Using exec in a simple background job isn't useful: exec myprogram; more stuff replaces the shell with myprogram and so doesn't run more stuff, unlike myprogram; more stuff which runs more stuff when myprogram terminates; but exec myprogram &...
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 ...
First of all, every time you execute a command, you shell will fork a new process, regardless of whether you run it with & or not. & only means you're running it in the background.
Note this is not very accurate. Some commands, like cd are shell functions and will usually not fork a new process. type cmd will usually tell you whether cmd is an ...
Redirect the output to /dev/null:
nohup ./myServer >& /dev/null &
Alternatively, if you want to discard the standard output but keep the standard error, you could use this:
nohup ./myServer > /dev/null &
You can find more details here if you need more control over the redirections (using bash):
Both have there own + and - :
nohup is good to use for running procs in background when proc don't
need any user input like HTTPD server or any other server proc like
nohup does create log in dir of proc execution. log file name
default is nohup.out
It avoids proc getting killed due to mistaken
ctrl+C , ctrl+D . Just a safe guard.
screen has a ton of features. It doesn't just "daemonize" a process, it's more of a window manager for terminals.
It can be used if the process needs input at some point, you can go and check the process's output, reconnect to its terminal, ...
So no, it's not just a matter of preference, they are not the same thing at all.
To make sure that your application is disassociated from its terminal - so that it will not interfere with foreground commands and will continue to run after you logout - nohup ensures that neither stdin nor stdout nor stderr are a terminal-like device. The documentation describes what actions it takes:
If the standard output is a terminal, all output ...
nohup and disown -h are not exactly the same thing.
With disown, a process is removed from the list of jobs in the current interactive shell. Running jobs after starting a background process and running disown will not show that process as a job in the shell. A disowned job will not receive a HUP from the shell when it exits (but see note at end).
nohup gedit &> /dev/null
is POSIX syntax and is the same as:
nohup gedit &
That is run nohup gedit in background and then do a > /dev/null redirection without running a command.
nohup gedit >& /dev/null
is not POSIX syntax and is the csh way to redirect both stdout and stderr to /dev/null. csh doesn't have the 2>&...
You should try setsid(1). Use it like you'd use nohup:
setsid command_which_takes_time input > output
This (as per the setsid(2) manpage), does a fork(2), an _exit(2) of the parent process, then the child process calls setsid(2) to create a new process group (session).
You can't kill that by logging out, and it's not part of the Bash job control ...
exec & => executes a process as a background process so you may continue using the same terminal for other jobs.
nohup => avoids all SIGHUP(terminate signal) and continues execution even if you terminal is closed.
exec process dies when a SIGHUP is received, but nohup process continues.
Is it ever useful to do nohup ... &? Yes. If you just start a process "in the background" with &, that new process still has membership in the original shell's "process group". If that shell or the process group gets certain signals (SIGHUP, for example), by default they exit. This means that if you run a process with & from a shell started by ...
set (and export) the variable before launching mvn
set the variable on the nohup launch:
FORMAVEN=valueForMaven nohup $COMMAND > logfile
use env to set the variable
COMMAND="env FORMAVEN=valueForMaven mvn clean install -P $MAVEN_PROFILE"
The nohup command is not a keyword; it can't be given a subshell as the command to run, and instead it requires an actual runnable command:
nohup bash -c 'sleep 120; echo "job done"' &
Bash is giving you a syntax error because it thinks you're trying to declare a function called "nohup", which is the only case where a bare parenthesis can appear in the ...
The reason why nohup is not helping you is because the program works with standard IO files.
Here is' an excerpt from Wiki Page for nohup:
Note - Nohupping
backgrounded jobs is typically used to avoid terminating them when
logging off from a remote SSH session. A different issue that often
arises in this situation is that ssh is refusing to log off ...
nohup only make program immune to SIGHUP and SIGQUIT signal. Modern shell maybe send other signals when you logout from your session, so there is no guarantee that your program is not killed, even running under nohup.
The better solution is using tmux or screen, or if you use bash, you can try:
$ java -jar project.jar &
You can get rid off the message if you redirect std error to std output:
nohup java -jar ./exhibitor-1.5.1/lib/exhibitor-1.5.1-jar-with-dependencies.jar -c file --fsconfigdir /opt/exhibitor/conf --hostname phx5qa01c.phx.qa.host.com > exhibitor.out 2>&1 &
Yet another option in place of the (chronically dysfunctional) nohup:
setsid java -jar project.jar </dev/zero &>/dev/null &
This effectively "daemonizes" the process. It is now owned by init, so will never get HUP'd, its I/O streams are safe, and it has been forked into the background.
See man setsid for more information. Unlike screen or ...
nohup runs an executable. You need to pass it an external command, i.e. an executable file. You can't call nohup on a shell construct such as an alias, function or builtin. nohup runs a new process, it doesn't run something inside the existing shell process (since nohup itself is a separate process), so nohup . … doesn't make sense.
nohup ./test.sh is the ...
On the assumption that you are using bash, ksh, zsh, or another similar shell, you can background the process, then run disown. Specifically, in bash you probably want disown -h.
From bash's help page on disown:
disown: disown [-h] [-ar] [jobspec ...]
Remove jobs from current shell.
Removes each JOBSPEC argument from the table of active jobs. ...
The standard recipe for running a remote command from a remote login like SSH is the following:
nohup command </dev/null >command.log 2>&1 &
If command is a shell script that takes care of logging to a file itself, then you could change command.log to /dev/null. Once you start this, log off right away.
You need everything on that line.
You made both cmd1 and cmd2 run in parallel. You said: “Start cmd2 in the background and sever any association with it. Start cmd1 in the background and sever any association with it.” You meant: “Start cmd2 in the background; when it's complete, start cmd1 (also in the background).” Since there is no longer any association with the background task, you need ...
perl may not be the most appropriate unless the IO::Pty module is installed.
First, maybe you don't need anything complicated if the given-thing-that-takes-long-time (gtttlt) can work OK with pipes.
nohup gtttlt <> input > output 2>&1 &
to start the gtttlt (input from a named pipe, output to a regular file). Then you ...