Re: TCP proxy for host on subnet

[<tomas@tuxteam.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jun 10, 2017 at 11:54:17AM +0100, Ron Leach wrote:
> On 06/06/2017 18:03, Greg Wooledge wrote:
> >
> >Once you're ready to deploy it, you would want to set it up as an
> >automatically respawning service, under systemd or one of the other
> >service managers.
> >
> 
> I seem to be having a problem stopping socat under Wheezy LTS using
> /etc/init.d.  I've created a socat start/stop script (by editing the
> example file provided by Debian in /etc/init.d/skeleton).  Then:

[...]

> Further, I don't seem to be able to *stop* socat without pressing ^C
> in the session [...]

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).

So if you want to achieve the same effect from "somewhere else", you'll
have to issue

  kill -INTR <pid>

where <pid> is the ID of the process you want to stop. Typically you
store that process ID somewhere (/var/run is a good place, typically
in a subdirectory there) and pick it up when you want to terminate.

In it simplest form, this will be the pattern:

====

# Script 1, start the process:
socat <many parameters> & # start process in the background
echo $! > /var/run/tunnel/pid

====

# Script 2, stop the process

PIDFILE=/var/run/tunnel.pid
test -f $PIDFILE && kill -TERM $(cat $PIDFILE) && rm -f $PIDFILE

====

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.

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.

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.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlk78iEACgkQBcgs9XrR2kaGcACfX/PC7GThPMpDlk6ze6mMxMuH
3l4An0G8kFonaRPSiJVyz0xzCYzMLJc1
=4k/o
-----END PGP SIGNATURE-----