Re: TCP proxy for host on subnet
On Sat, Jun 10, 2017 at 03:20:33PM +0200, tomas@tuxteam.de wrote:
> What the "session" (actually the terminal) is doing when you hit ^C is
> to send a signal (typically number 2, SIGINT) to the running process.
SIGINT is sent to all the foreground processes, not just one. This
becomes important when writing shell scripts (sometimes). If you run
a shell script in a terminal, and that script runs some process in the
foreground, and you press Ctrl-C, both the shell *and* the foreground
process receive SIGINT and handle it however they've been instructed to.
> What the "session" (actually the terminal) is doing when you hit ^C is
> to send a signal (typically number 2, SIGINT) to the running process.
>
> (To find out which one exactly, you can issue "stty -a" on your terminal;
> an entry like "intr = ^C" is telling you that the INT (called here "intr",
> confusing, I know) signal is bound to the CTRL-C key (abbreviated ^C).
You've got this backwards. The terminal driver has a concept of "the
key that causes me to send SIGINT to all the foreground processes",
a.k.a "the interrupt key". The stty command uses the "intr" label for
this feature. stty -a will show you which key is currently bound to it.
On Linux and BSD systems, by default it is Ctrl-C. On commercial System V
Unix-based machines, it's typically DEL.
The interrupt key can be changed with the stty command, or by calling
various ioctl() functions in C. These operations take effect on the
current terminal only, and will (conceivably) affect any process running
inside that terminal.
> So if you want to achieve the same effect from "somewhere else", you'll
> have to issue
>
> kill -INTR <pid>
Two mistakes here.
1) It's -INT, not -INTR.
2) Sending SIGINT to a single process is *not* the same as pressing
Ctrl-C in a terminal. Ctrl-C sends SIGINT to all the forground
processes, not just one.
> # Script 1, start the process:
> socat <many parameters> & # start process in the background
> echo $! > /var/run/tunnel/pid
This is how System V init/rc.d work. It's a really bad kludge, and I
wouldn't recommend designing new systems this way.
> Of course, there are many details to "get right", like what happens when
> the process dies, leaving behind a stale PID file, what happens when the
> PID is reused for another process and you kill the wrong one, etc.
Yes, exactly. These are some of the issues that the sysvinit model faces.
> That's what "classical" sys V init does, and you will discover this
> pattern (wrapped in neat functions) if you look around in the /etc/init.d
> start/stop files.
If you're a historian. Otherwise, I wouldn't recommend reading these.
They will warp your brain, and teach you bad habits.
> Under "service managers", like systemd or runit, it's the parent process
> what keeps the service process "under control", and there are special
> commands you send to the parent to do this. More or less as the terminal
> does for you above.
These are infinitely preferable. They're simpler *and* more robust.
Aso see <http://mywiki.wooledge.org/ProcessManagement> for a more
general discussion of processes, and why the PID file model fails.
Reply to: