How can I redirect nohup output to a specified file?
nohup dotnet application.dll > out.log 2>&1 &
is the correct form.
> out.log
redirects STDOUT to the file out.log
.
2>&1
redirects fd2 (STDERR) to fd1 (STDOUT), which is already redirected to the file out.log
.
Your problem lies in the file permissions (or a read-only filesystem). Prepending sudo
to your command can't fix this, because only nohup dotnet application.dll
is executed as root by sudo
, the output redirection is done by bash with your normal user privileges. You can work around this by calling a separate shell with root privileges:
sudo sh -c 'nohup dotnet application.dll > out.log 2>&1 &'
using nohup - output to file and console
Try this to run and log the output in file.
nohup ./program > Output.txt | tail -F Output.txt &
If you want to run it in background:
nohup ./program > Output.txt &
Can I change the name of `nohup.out`?
nohup some_command &> nohup2.out &
and voila.
Older syntax for Bash version < 4:
nohup some_command > nohup2.out 2>&1 &
How do I use the nohup command without getting nohup.out?
The nohup
command only writes to nohup.out
if the output would otherwise go to the terminal. If you have redirected the output of the command somewhere else - including /dev/null
- that's where it goes instead.
nohup command >/dev/null 2>&1 # doesn't create nohup.out
Note that the >/dev/null 2>&1
sequence can be abbreviated to just >&/dev/null
in most (but not all) shells.
If you're using nohup
, that probably means you want to run the command in the background by putting another &
on the end of the whole thing:
nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out
On Linux, running a job with nohup
automatically closes its input as well. On other systems, notably BSD and macOS, that is not the case, so when running in the background, you might want to close input manually. While closing input has no effect on the creation or not of nohup.out
, it avoids another problem: if a background process tries to read anything from standard input, it will pause, waiting for you to bring it back to the foreground and type something. So the extra-safe version looks like this:
nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal
Note, however, that this does not prevent the command from accessing the terminal directly, nor does it remove it from your shell's process group. If you want to do the latter, and you are running bash, ksh, or zsh, you can do so by running disown
with no argument as the next command. That will mean the background process is no longer associated with a shell "job" and will not have any signals forwarded to it from the shell. (A disown
ed process gets no signals forwarded to it automatically by its parent shell - but without nohup
, it will still receive a HUP
signal sent via other means, such as a manual kill
command. A nohup
'ed process ignores any and all HUP
signals, no matter how they are sent.)
Explanation:
In Unixy systems, every source of input or target of output has a number associated with it called a "file descriptor", or "fd" for short. Every running program ("process") has its own set of these, and when a new process starts up it has three of them already open: "standard input", which is fd 0, is open for the process to read from, while "standard output" (fd 1) and "standard error" (fd 2) are open for it to write to. If you just run a command in a terminal window, then by default, anything you type goes to its standard input, while both its standard output and standard error get sent to that window.
But you can ask the shell to change where any or all of those file descriptors point before launching the command; that's what the redirection (<
, <<
, >
, >>
) and pipe (|
) operators do.
The pipe is the simplest of these... command1 | command2
arranges for the standard output of command1
to feed directly into the standard input of command2
. This is a very handy arrangement that has led to a particular design pattern in UNIX tools (and explains the existence of standard error, which allows a program to send messages to the user even though its output is going into the next program in the pipeline). But you can only pipe standard output to standard input; you can't send any other file descriptors to a pipe without some juggling.
The redirection operators are friendlier in that they let you specify which file descriptor to redirect. So 0<infile
reads standard input from the file named infile
, while 2>>logfile
appends standard error to the end of the file named logfile
. If you don't specify a number, then input redirection defaults to fd 0 (<
is the same as 0<
), while output redirection defaults to fd 1 (>
is the same as 1>
).
Also, you can combine file descriptors together: 2>&1
means "send standard error wherever standard output is going". That means that you get a single stream of output that includes both standard out and standard error intermixed with no way to separate them anymore, but it also means that you can include standard error in a pipe.
So the sequence >/dev/null 2>&1
means "send standard output to /dev/null
" (which is a special device that just throws away whatever you write to it) "and then send standard error to wherever standard output is going" (which we just made sure was /dev/null
). Basically, "throw away whatever this command writes to either file descriptor".
When nohup
detects that neither its standard error nor output is attached to a terminal, it doesn't bother to create nohup.out
, but assumes that the output is already redirected where the user wants it to go.
The /dev/null
device works for input, too; if you run a command with </dev/null
, then any attempt by that command to read from standard input will instantly encounter end-of-file. Note that the merge syntax won't have the same effect here; it only works to point a file descriptor to another one that's open in the same direction (input or output). The shell will let you do >/dev/null <&1
, but that winds up creating a process with an input file descriptor open on an output stream, so instead of just hitting end-of-file, any read attempt will trigger a fatal "invalid file descriptor" error.
Redirect nohup to stdout on a script
You can fix your command by using the shell to indirectly start your program so that you can redirect its output rather than the output of nohup:
nohup bash -c "exec python tester.py > /proc/1/fd/1" 2> /dev/null &
This isn't the best option but it at least corrects the issue that made your attempts fail.
redirect nohup stdout and flush
You'll need to take a look at my answer to another question here:
Linux non-blocking fifo (on demand logging).
Assuming that by now you've got the ftee
program ready, if you call your app like this:
$ mkfifo /tmp/mylog
$ nohup ruby myapp.rb 2>&1 | tee output.log | ftee /tmp/mylog &
you'll get:
- full output log int the file
output.log
- current output of your app available on demand via the
/tmp/mylog
fifo
Now if you want to just take a peek at your prog's latest output do:
$ cat /tmp/mylog
Hope this helps.
How redirect nohup stdout to stdin
The nohup command purposefully detaches itself from the stdin, so there is nothing it expects to read in itself, and thus I think what you are really after in this question, is redirecting the output of nohup as the stdin for the next command. (Well somebody has to read the stdin, and it ain't nohup.)
Further, POSIX mandates that the output goes to the nohup.out file in the working directory, if the file can be successfully opened. So what you can do is to wire the stdin of the following commands from the nohup.out file. For instance:
$ nohup echo Hello 2>/dev/null; read VAR 0<nohup.out; echo "VAR=$VAR"
VAR=Hello
How do I use the nohup command without getting nohup.out?
The nohup
command only writes to nohup.out
if the output would otherwise go to the terminal. If you have redirected the output of the command somewhere else - including /dev/null
- that's where it goes instead.
nohup command >/dev/null 2>&1 # doesn't create nohup.out
Note that the >/dev/null 2>&1
sequence can be abbreviated to just >&/dev/null
in most (but not all) shells.
If you're using nohup
, that probably means you want to run the command in the background by putting another &
on the end of the whole thing:
nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out
On Linux, running a job with nohup
automatically closes its input as well. On other systems, notably BSD and macOS, that is not the case, so when running in the background, you might want to close input manually. While closing input has no effect on the creation or not of nohup.out
, it avoids another problem: if a background process tries to read anything from standard input, it will pause, waiting for you to bring it back to the foreground and type something. So the extra-safe version looks like this:
nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal
Note, however, that this does not prevent the command from accessing the terminal directly, nor does it remove it from your shell's process group. If you want to do the latter, and you are running bash, ksh, or zsh, you can do so by running disown
with no argument as the next command. That will mean the background process is no longer associated with a shell "job" and will not have any signals forwarded to it from the shell. (A disown
ed process gets no signals forwarded to it automatically by its parent shell - but without nohup
, it will still receive a HUP
signal sent via other means, such as a manual kill
command. A nohup
'ed process ignores any and all HUP
signals, no matter how they are sent.)
Explanation:
In Unixy systems, every source of input or target of output has a number associated with it called a "file descriptor", or "fd" for short. Every running program ("process") has its own set of these, and when a new process starts up it has three of them already open: "standard input", which is fd 0, is open for the process to read from, while "standard output" (fd 1) and "standard error" (fd 2) are open for it to write to. If you just run a command in a terminal window, then by default, anything you type goes to its standard input, while both its standard output and standard error get sent to that window.
But you can ask the shell to change where any or all of those file descriptors point before launching the command; that's what the redirection (<
, <<
, >
, >>
) and pipe (|
) operators do.
The pipe is the simplest of these... command1 | command2
arranges for the standard output of command1
to feed directly into the standard input of command2
. This is a very handy arrangement that has led to a particular design pattern in UNIX tools (and explains the existence of standard error, which allows a program to send messages to the user even though its output is going into the next program in the pipeline). But you can only pipe standard output to standard input; you can't send any other file descriptors to a pipe without some juggling.
The redirection operators are friendlier in that they let you specify which file descriptor to redirect. So 0<infile
reads standard input from the file named infile
, while 2>>logfile
appends standard error to the end of the file named logfile
. If you don't specify a number, then input redirection defaults to fd 0 (<
is the same as 0<
), while output redirection defaults to fd 1 (>
is the same as 1>
).
Also, you can combine file descriptors together: 2>&1
means "send standard error wherever standard output is going". That means that you get a single stream of output that includes both standard out and standard error intermixed with no way to separate them anymore, but it also means that you can include standard error in a pipe.
So the sequence >/dev/null 2>&1
means "send standard output to /dev/null
" (which is a special device that just throws away whatever you write to it) "and then send standard error to wherever standard output is going" (which we just made sure was /dev/null
). Basically, "throw away whatever this command writes to either file descriptor".
When nohup
detects that neither its standard error nor output is attached to a terminal, it doesn't bother to create nohup.out
, but assumes that the output is already redirected where the user wants it to go.
The /dev/null
device works for input, too; if you run a command with </dev/null
, then any attempt by that command to read from standard input will instantly encounter end-of-file. Note that the merge syntax won't have the same effect here; it only works to point a file descriptor to another one that's open in the same direction (input or output). The shell will let you do >/dev/null <&1
, but that winds up creating a process with an input file descriptor open on an output stream, so instead of just hitting end-of-file, any read attempt will trigger a fatal "invalid file descriptor" error.
Where will be nohup file created/stored
Could you check home directory.
also you can redirect as below;
nohup /usr/hp/ism/jboss-3.2.8.SP1/bin/run.sh &> /tmp/nohup.out
man nohup ;
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'.
Related Topics
Merge/Join Two Tables Fast Linux Command Line
Interrupt Handling and User Space Notification
How to Check a File Exists and Execute a Command If Not
How to Force Node.Js Require to Be Case Sensitive
What Does "$" Give Us Exactly in a Shell Script
How to Release Hugepages from the Crashed Application
Run Silverlight with Apache Server (Under Linux)
How to Run Elasticsearch 2.1.1 as Root User in Linux MAChine
How to Change the Soname of a Binary Directly
How to Read the Last Line of a Text File into a Variable Using Bash
Ldd Doesn't Work on Dynamically Linked Binary
How to Redirect from Audio Output to Mic Input Using Pulseaudio
Determine Usb Device File Path
What Is File Hole and How Can It Be Used
Tail Inverse/Printing Everything Except the Last N Lines