Processes receive signals from other processes or kernel as a warning or as a request to make some change in state. Receiving processes can block, ignore or catch signals, except SIGKILL which does what the name says. A process receives SIGHUP (hangup signal) when its controlling terminal (virtual or pseudo) disconnects or its controlling process (which is usually a shell) terminates. Quoted from adb shell source:
PTYs automatically send SIGHUP to the slave-side process when the master side of the PTY closes
* See Terminals and Shells on Android for details on PTYs
Process can then handle the signal to continue its execution or just gets killed by the kernel.
nohup makes a process run (usually in background) by simply ignoring SIGHUP even if the controlling terminal closes. Additionally if FDs 0, 1 and 2 of the process are attached to the terminal, nohup redirects STDIN from /dev/null and STDOUT/STDERR to nohup.out file.
Android's built-in /system/bin/nohup has some bad implementation like many other applets of toybox. It replaces STDIN with nothing and leaves STDERR attached to the terminal. So all shell commandline tools which are related to system_server behave unexpectedly because of no FD 0.
Solution is to use nohup e.g. from busybox or do:
nohup tether.sh </dev/null &
Or without nohup:
tether.sh </dev/null &>/sdcard/usb.log &
In order to make sure a program ignores SIGHUP, add trap '' 1 to script above the program to be executed. But it's not required with Android's default MirBSD Korn Shell (/system/bin/sh) which doesn't send SIGHUP to all jobs (children processes) in the same session i.e. attached to the same terminal. So nohup or trap isn't essentially required, whether shell exits or gets killed.
Secondly mksh doesn't detach from terminal(s) completely because in addition to STDIN/OUT/ERR, it attaches to /dev/tty directly (ref). So detaching FDs 0/1/2 doesn't suffice. However there's a daemon mode which completely detaches the command from terminal:
/system/bin/sh -T- tether.sh
Also mksh unblocks all signals, though not relevant here.
bash provides better job management; user can configure with huponexit whether or not to always send SIGHUP to all jobs on exit (ref). Bash's built-in disown command can be used to exclude jobs from receiving signals.
To keep script running in foreground, a multiplexer like tmux or screen can be used. That's what I do, particularly with su binaries from rooting solutions which don't detach (due to limited implementation of pseudo-terminals), when a program is running in background. See this issue for details.
RELATED: How to run an executable on boot and keep it running?