So what does the man page tell us about huponexit?
If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.
EDIT: Emphasizing that it is a LOGIN shell.
EDIT 2: interactive deserves equal emphasis
I would disconnect the command from its standard input/output and error flows:
nohup python3 -u <script> </dev/null >/dev/null 2>&1 &
ssh needs an indicator that doesn't have any more output and that it does not require any more input. Having something else be the input and redirecting the output means ssh can safely exit, as input/output is not coming from or going to the terminal. This means the input has to come from somewhere else, and the output (both STDOUT and STDERR) should go somewhere else.
The </dev/null part specifies /dev/null as the input for <script>. Why that is useful here:
Redirecting /dev/null to stdin will give an immediate EOF to any read
call from that process. This is typically useful to detach a process
from a tty (such a process is called a daemon). For example, when
starting a background process remotely over ssh, you must redirect
stdin to prevent the process waiting for local input.
https://stackoverflow.com/questions/19955260/what-is-dev-null-in-bash/19955475#19955475
Alternatively, redirecting from another input source should be relatively safe as long as the current ssh session doesn't need to be kept open.
With the >/dev/null part the shell redirects the standard output into /dev/null essentially discarding it. >/path/to/file will also work.
The last part 2>&1 is redirecting STDERR to STDOUT.
There are three standard sources of input and output for a program.
Standard input usually comes from the keyboard if it’s an interactive
program, or from another program if it’s processing the other
program’s output. The program usually prints to standard output, and
sometimes prints to standard error. These three file descriptors (you
can think of them as “data pipes”) are often called STDIN, STDOUT, and
STDERR.
Sometimes they’re not named, they’re numbered! The built-in numberings
for them are 0, 1, and 2, in that order. By default, if you don’t name
or number one explicitly, you’re talking about STDOUT.
Given that context, you can see the command above is redirecting
standard output into /dev/null, which is a place you can dump anything
you don’t want (often called the bit-bucket), then redirecting
standard error into standard output (you have to put an & in front of
the destination when you do this).
The short explanation, therefore, is “all output from this command
should be shoved into a black hole.” That’s one good way to make a
program be really quiet!
What does > /dev/null 2>&1 mean? | Xaprb
Best Answer
set +bThe default mode. In this mode, every time
bashis about to print its prompt, it first checks to see whether any background jobs have stopped or terminated, and if so it prints notification messages before displaying the prompt.set +bnever corrupts the display, but it has its own problems. In particular, suppose you are testing a GUI program whose source code you're editing in a separate editor window. (Let's assume it's written in an interpreted language.) You might have a terminal window in which you keep typing the same command,myprogram &. Every time you make changes to the program and want to restart it, you close down the current instance of it, and repeat this command in your shell window. Nowbashwill launch the new instance of the program before printing the notification that the old one has finished - and because printing that notification is the moment at which the job number allocation gets reset, this also means that your job numbers will increase without bound unless you deliberately hit Return at a point when no background job is running. Eventually, one instance of your program will hang and you'll have to typekill %134, instead of thekill %1you would prefer.set -bIn this mode, when any background job stops or terminates,
bashreceives a SIGCHLD signal, and its signal handler displays the notification message immediately - even ifbashis currently in the middle of waiting for a foreground process to complete.set -bhas no awareness of the state of the terminal, so its notifications are likely to corrupt the display of any full-screen application you might be running (such as a text editor or MUA). In particular, this mode cannot even interact sensibly withbash's own command-line editing! Try runningsleep 1 &in this mode, and then immediately beginning to type a command line. You will find that when the notification is printed, you are left with the display in a somewhat non-obvious state.Source of all this found here.