Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #181762 > unrolled thread

TCP proxy for host on subnet

Back to article view | Back to linux.debian.user

Contents

  TCP proxy for host on subnet Ron Leach <ronleach@tesco.net> - 2017-06-05 13:40 +0200
    Re: TCP proxy for host on subnet Darac Marjal <mailinglist@darac.org.uk> - 2017-06-05 15:30 +0200
    Re: TCP proxy for host on subnet Henning <henning@itcfollmann.com> - 2017-06-05 15:40 +0200
      Re: TCP proxy for host on subnet Ron Leach <ronleach@tesco.net> - 2017-06-06 12:00 +0200
        Re: TCP proxy for host on subnet <tomas@tuxteam.de> - 2017-06-06 12:50 +0200
          Re: TCP proxy for host on subnet Henning Follmann <hfollmann@itcfollmann.com> - 2017-06-06 15:30 +0200
            Re: TCP proxy for host on subnet tomas@tuxteam.de - 2017-06-06 16:30 +0200
        Re: TCP proxy for host on subnet Henning Follmann <hfollmann@itcfollmann.com> - 2017-06-06 15:40 +0200
          Re: TCP proxy for host on subnet Ron Leach <ronleach@tesco.net> - 2017-06-06 18:40 +0200
            Re: TCP proxy for host on subnet Greg Wooledge <wooledg@eeg.ccf.org> - 2017-06-06 19:10 +0200
              Re: TCP proxy for host on subnet Ron Leach <ronleach@tesco.net> - 2017-06-10 13:00 +0200
                Re: TCP proxy for host on subnet <tomas@tuxteam.de> - 2017-06-10 15:30 +0200
                  Re: TCP proxy for host on subnet Greg Wooledge <wooledg@eeg.ccf.org> - 2017-06-13 14:40 +0200
                    Re: TCP proxy for host on subnet <tomas@tuxteam.de> - 2017-06-13 21:20 +0200

#181762 — TCP proxy for host on subnet

List, good morning,

I'm looking for a way to provide a tcp proxy, which can run as a 
service on a Wheezy-LTS host, for a single (higher-order) port.  I 
have looked at two packages, but neither is quite suitable.

Connect-proxy ( https://packages.debian.org/wheezy/connect-proxy ) 
works well except that it only runs by cli command (not as a service), 
and it exits quite quickly - possibly when there is no activity.

Balance ( https://packages.debian.org/wheezy/balance) looked very 
interesting, not least because it is mainly aimed at sharing traffic 
across multiple uplinks and with failover, but suffers from a flaw(?) 
which means that it does not accept incoming IPv4 traffic from another 
machine on its local subnet
( https://sourceforge.net/p/balance/bugs/9/ ); it does work when 
accepting connections from localhost, as per the work-around in that 
report.  But in our case the inbound traffic is from another host on 
the subnet; on testing we encountered exactly the problem described in 
that report.

I have to rule out an SSH tunnel solution (which would, otherwise, 
work) because SSH actually provides a 'continuous' operating 'channel' 
to the destination host and, since the LAN hosting these subnets is on 
a WAN with a dynamically assigned IP address, an SSH connection will 
keep dropping each time the IP address is re-assigned.  (IP 
re-assignments seem to be happening every overnight, at present.)

Reading around, I think that various folks have hacked a specific 
solution to this kind of problem using IPtables, but I don't really 
want to do that because I didn't want to alter whatever IP routing 
Debian has installed - neither do I understand it enough.  I'd prefer, 
if possible, to use a package; we only need to add this particular 
one-off port-to-host forwarding, and only in that direction, there'll 
be no inbound traffic (other than replies in a transaction sequence).

I realise that a router with almost totally restricted capability 
(except for this one port) would also solve this problem but that is 
quite a big solution for what ought really be a simple proxy.

Has anyone any experience or suggestions for a single port TCP proxy 
solution that would be always-on?

regards, Ron

[toc] | [next] | [standalone]

#181773

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 05, 2017 at 12:37:48PM +0100, Ron Leach wrote:
>List, good morning,
>
>I'm looking for a way to provide a tcp proxy, which can run as a 
>service on a Wheezy-LTS host, for a single (higher-order) port.  I 
>have looked at two packages, but neither is quite suitable.

Depending on the protocol, might something like nginx work? It's perhaps
using a sledgehammer to crack a nut, but it does include the ability to
proxy arbitrary tcp and udp connections and forward them on to one or
more "back-end" hosts.

https://www.nginx.com/resources/admin-guide/tcp-load-balancing/


-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#181774

> On Jun 5, 2017, at 7:37 AM, Ron Leach <ronleach@tesco.net> wrote:
> 
> 
> I'm looking for a way to provide a tcp proxy

socat

-H

[toc] | [prev] | [next] | [standalone]

#181798

On 05/06/2017 14:08, Henning wrote:
>
> socat
>

Henning, thank you for that.  socat seems a very flexible package.

Have you used it yourself, at all?  I couldn't see from the 
documentation how to terminate socat.  I was planning to use a 
variation of one of their examples, like this:

socat -d -d -lmlocal2 \
TCP4-LISTEN:3129,su=nobody,fork,range=192.168.0.0/24,reuseaddr \
TCP4:name.server.tld:4444

I was also unsure whether socat would hold open a connection to 
name.server.tld even if no transactions were taking place, or whether 
socat would only open the connection each time traffic arrived on 3129 
and it forked another child process.  The documentation seems to imply 
that the 'open' takes place before traffic and before forking, which 
suggests to me that the connection is opened and remains open.  I'd 
prefer an arrangement where a connection was made each time a 
transaction sequence was initiated by traffic on the local, incoming, 
3129 port (in my example), and then closed when traffic stopped.  I'll 
reread the documentation, anyway.

May I, in passing, note that Darac was kind enough to say, On 
05/06/2017 14:21:

 >
 > Depending on the protocol, might something like nginx work? It's
 > perhaps using a sledgehammer to crack a nut, but it does include
 > the ability to proxy arbitrary tcp and udp connections and forward
 > them on to one or more "back-end" hosts.
 >

Darac, that was an interesting option.  Though the learning curve 
makes it difficult to quickly implement this to solve the specific 
problem I have, using nginx would also help me with a different 
information presentation problem to solve, by deploying a web server 
to present quite a lot of static information in an accessible form for 
client machines that use http.

I hadn't realised that nginx can be configured this way, and I'll 
consider using this mode as well as the http service that I do/will 
need on this LAN segment.

regards, Ron

[toc] | [prev] | [next] | [standalone]

#181802

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

On Tue, Jun 06, 2017 at 10:59:30AM +0100, Ron Leach wrote:
> On 05/06/2017 14:08, Henning wrote:
> >
> >socat
> >
> 
> Henning, thank you for that.  socat seems a very flexible package.
> 
> Have you used it yourself, at all?  I couldn't see from the
> documentation how to terminate socat.  I was planning to use a
> variation of one of their examples, like this:

I'm using it all the time, to have ssh access through a corporate
firewall.

Corporate firewalls and their priests tend to believe in Numerology,
and for some $REASONS ports 80 and 443 are Good and all other ~65K
are Evil. So I wrap my ssh connections in a port 443 tunnel --
for good measure I wrap that in SSL (I don't even want to know
whether our corporate firewall does stateful inspection, and I guess
there's nobody in house who knows: some higher-order subcontractor
perhaps [1]).

Anyway, on my laptop "lappy" (some names changed, to protect
the innocent:

  myself: my user name
  lappy: my "road warrior" laptop
  example.net: my base station "out there" with a fixed IP
  example.tun: fake name for my base station, as viewed
               from lappy through the tunnel)

to access example.net:

  myself@lappy:~$ cat ~/bin/tun
  #!/bin/bash
  TLSDIR=/home/myself/.tls

  socat TCP4-LISTEN:2023,fork,reuseaddr \
        OPENSSL:example.net:443,pf=ip4,cert=$TLSDIR/lappy/cert.pem,key=$TLSDIR/lappy/key.pkcs8,cafile=$TLSDIR/root/cert.pem

As you can see, I use my own self-signed certificate. I'd notice
if our firewall tried to mess with the traffic (unless they are
able to break SSL to MITM me, but I think they are too incompetent
to even spell that; OTOH that's exactly they'd want me to think
*if* they were halfway competent, so there you are :)

On the base station side (which we nicknamed example.net), I have

  myself@myselfium:~$ cat .tls/runsocat
  #!/bin/sh
  # Must be root!
  CERTS=/home/myself/.tls/certs
  /usr/bin/socat \
    -lf socat-443.log \
    OPENSSL-LISTEN:443,su=myself,reuseaddr,pf=ip4,fork,cert=$CERTS/example.tun/cert.pem,key=$CERTS/example.tun/key1.pkcs8,cafile=$CERTS/root/cert.pem \
    TCP4:localhost:22 &
  exit 0

Combine this with some ssh magic (if I use the target address
to be example.tun, the ssh client on lappy knows to knock on
localhost:2023, where the tunnel's proximal end is listening),
and you have a pretty automated tunnel. The next step would
be actually using a TUN or TAP device and setting up routing
tables, like the grown-ups do ;-P

Of course, I could have set up the ssh daemon at 443 on the
base station, but...

 - traffic doesn't quite "look" like SSL. I don't even want
   to find out whether corp firewall freaks out on this

 - I might someday want to run a "real" https on 443 on
   base station. Then I could multiplex on SNI host name
   to decide whether it's a real https request or someone
   is knocking at my tunnel's door.

Enjoy, feel free to ask things.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlk2iL8ACgkQBcgs9XrR2kbEJACeIk6ikLPvnyBDbNK1MSXXH+R/
wEYAn29uOt6JK2dm+UBMuBKmT2wLiZBt
=0ZJz
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#181820

On Tue, Jun 06, 2017 at 12:49:35PM +0200, tomas@tuxteam.de wrote:
> On Tue, Jun 06, 2017 at 10:59:30AM +0100, Ron Leach wrote:
> > On 05/06/2017 14:08, Henning wrote:
> > >
> > >socat
> > >
> > 
> > Henning, thank you for that.  socat seems a very flexible package.
> > 
> > Have you used it yourself, at all?  I couldn't see from the
> > documentation how to terminate socat.  I was planning to use a
> > variation of one of their examples, like this:
> 
> I'm using it all the time, to have ssh access through a corporate
> firewall.
> 
> Corporate firewalls and their priests tend to believe in Numerology,
> and for some $REASONS ports 80 and 443 are Good and all other ~65K
> are Evil. So I wrap my ssh connections in a port 443 tunnel --
> for good measure I wrap that in SSL (I don't even want to know
> whether our corporate firewall does stateful inspection, and I guess
> there's nobody in house who knows: some higher-order subcontractor
> perhaps [1]).
> 
> Anyway, on my laptop "lappy" (some names changed, to protect
> the innocent:
> 
Or the guilty one from getting fired fore blatantly violating corporate
rules?

Is that you they are writing about here?
https://arstechnica.com/security/2017/05/defense-contractor-stored-intelligence-data-in-amazon-cloud-unprotected/

-H

[toc] | [prev] | [next] | [standalone]

#181828

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

On Tue, Jun 06, 2017 at 09:29:06AM -0400, Henning Follmann wrote:
> On Tue, Jun 06, 2017 at 12:49:35PM +0200, tomas@tuxteam.de wrote:

[...]

> > Corporate firewalls and their priests tend to believe in Numerology,

[...]

> > Anyway, on my laptop "lappy" (some names changed, to protect
> > the innocent:
> > 
> Or the guilty one from getting fired fore blatantly violating corporate
> rules?

To be fair, I'm the one to help out when someone needs to know how
things look "from the outside" and similar things. If that gets
me fired some day... too bad, so sad.

> Is that you they are writing about here?
> https://arstechnica.com/security/2017/05/defense-contractor-stored-intelligence-data-in-amazon-cloud-unprotected/

:-)

Based on the patterns I observe here, doom is coming from some
random printer living in the internal net and phoning home, or
from some javascript plus some browser vulnerability, or whatever.

I do take some care to avoid corp data leaving the barn. Actually
some more than others -- actually I seem to be one of the few
here with a working disk encryption on the laptop (not standard
here because "virus scanner"). So, well. Giveth and taketh and
that.

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

iEYEARECAAYFAlk2uncACgkQBcgs9XrR2kZ5ngCeMPV+P52NIU5nDSP1hPychXZH
m3UAn02TKJqWgGs4+WdKOgbD02mAWknV
=ho2S
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#181822

On Tue, Jun 06, 2017 at 10:59:30AM +0100, Ron Leach wrote:
> On 05/06/2017 14:08, Henning wrote:
> >
> >socat
> >
> 
> Henning, thank you for that.  socat seems a very flexible package.
> 
> Have you used it yourself, at all?  I couldn't see from the documentation

Yes I connect a serial port over network.

> how to terminate socat.  I was planning to use a variation of one of their
> examples, like this:

terminate in terms of "stopping"? I think SIGHUP will work.

> 
> socat -d -d -lmlocal2 \
> TCP4-LISTEN:3129,su=nobody,fork,range=192.168.0.0/24,reuseaddr \
> TCP4:name.server.tld:4444
> 
> I was also unsure whether socat would hold open a connection to
> name.server.tld even if no transactions were taking place, or whether socat
> would only open the connection each time traffic arrived on 3129 and it
> forked another child process.  The documentation seems to imply that the
> 'open' takes place before traffic and before forking, which suggests to me
> that the connection is opened and remains open.  I'd prefer an arrangement
> where a connection was made each time a transaction sequence was initiated
> by traffic on the local, incoming, 3129 port (in my example), and then
> closed when traffic stopped.  I'll reread the documentation, anyway.
> 

Well,wel,  aren't we a bit high maintenance? However I like how you ask
questions intelligently. IMO it's half the way to come to a solution. A
rare sight these days. With the fact that socat is pretty much the
universal patch cable, you are expecting too much here.
It seems you are looking for a protocol aware proxy. If you let us know
what protocol ...


-H
-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#181833

On 06/06/2017 14:22, Henning Follmann wrote:
> On Tue, Jun 06, 2017 at 10:59:30AM +0100, Ron Leach wrote:
>>
>> I was also unsure whether socat would hold open a connection to
>> name.server.tld even if no transactions were taking place, or whether socat
>> would only open the connection each time traffic arrived on 3129 and it
>> forked another child process.  The documentation seems to imply that the
>> 'open' takes place before traffic and before forking, which suggests to me
>> that the connection is opened and remains open.  I'd prefer an arrangement
>> where a connection was made each time a transaction sequence was initiated
>> by traffic on the local, incoming, 3129 port (in my example), and then
>> closed when traffic stopped.
>>
>
> [...] With the fact that socat is pretty much the
> universal patch cable, you are expecting too much here.
> It seems you are looking for a protocol aware proxy.
>

Not wanting the proxy be protocol-aware, but considering what 'states' 
the proxy, and the destination-server, might remain in for extended 
periods of time.  Just keeping in mind resource consumption and 
potential for congestion, so that performance issues don't turn out to 
compromise what - really - looks to be a promising solution.

In the meantime, between posts, I have done some testing and, because 
I could not find much comment about this aspect, I'd like to share 
here what I found.

I altered the command to log to a file in /var/log, and to log more 
details (options -d -d -d), including the 'connection' open and close, 
and the traffic sequences.

For tests, I used telnet on a source machine on this subnet, and socat 
on a proxy server to reach an smtp server we have at another site; I 
only passed the

EHLO,
HELP, and
QUIT

commands, because I did not want to falsely trigger the intrusion 
detection systems on the server.  But those few commands served to 
reveal what socat was doing.

The socat command I used was

$ socat -d -d -d -lf /var/log/socat \ 
TCP4-LISTEN:3129,su=nobody,fork,range=192.168.0.0/24,reuseaddr \ 
TCP4:server.ourdomain.tld:4444

Here's what I found.

1.  socat stopped right away; the log showed that socat could not 
create its child processes. I wondered whether this might be because 
socat needed to run as root.  su, and then # socat started ok.

2.  socat did not 'detach' from the keyboard session, so the screen 
remained with a blank line and no shell prompt.  [This means that if I 
invoke a solution this way, I will have to have a session running all 
the time that I want socat to run.]

3.  Running telnet from a different test machine:
$ telnet 192.168.0.123 3129
resulted in:
220 server.ourdomain.tld ESMTP Exim Tue .........
and the simple transaction sequence followed, ending with
quit
221 server.ourdomain.tld closing connection
$
So the proxying worked fine.  But what did socat do, itself?

4.  On the proxy machine, /var/log/socat showed

a.  socat set itself up, listening on (in our test) 3129;
- no child processes at this point, and
- *no* outbound connection to server.ourdomain.tld - yet

b.  A few seconds or so later, socat 'accepted connection' from the 
telnet test machine, and
- forked a child process, while
- remaining listening for any other connection from the acceptable 
range of IP addresses

c.  Meanwhile, the child process
- 'opened' a connection to server.ourdomain.tld:4444, and
- bridged that channel to the input channel from telnet machine, and
- transferred 88 bytes (the Exim 220 welcome message)
- There followed the short transaction exchange, then finally socat
- sensed 'EOF' on both sides and shut down transmission for both sides
- and the child process exited

5.  socat master process
- was (and is) still running
- and went on to pass additional test sequences from a variety of machines

6.  I can close socat using ^C

Henning, for a universal patch cable, it's pretty good, and seems to 
work sensibly in terms of resources, too, releasing connections and 
processes as they reach a quiescent state.

A useful suggestion; much appreciated.

regards, Ron

[toc] | [prev] | [next] | [standalone]

#181835

On Tue, Jun 06, 2017 at 05:39:19PM +0100, Ron Leach wrote:
> 2.  socat did not 'detach' from the keyboard session, so the screen 
> remained with a blank line and no shell prompt.  [This means that if I 
> invoke a solution this way, I will have to have a session running all 
> the time that I want socat to run.]

Excellent.  Services should be foreground processes, exactly like
this.  You're running it in a terminal now, because you're still in
the testing stages.

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.  E.g. under systemd, you'd create a file in
/etc/systemd/system/ with a name ending with .service and contents
something like this:

==============================================
[Unit]
Description=Your description
After=network.target

[Service]
ExecStart=/usr/bin/socat ...
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
==============================================

Then "systemctl daemon-reload" and "systemctl enable yourservice.service"
and "systemctl start yourservice.service" and you're done.

[toc] | [prev] | [next] | [standalone]

#182009

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:

# service socat start

works, socat runs, logs the uses of the proxy, and so on.  But, the 
'session', in the sense of the keyboard and screen, still runs and 
does not go into any kind of background.  Sure, I realise I am running 
from a terminal - but my uncertainty is that this 'continuous 
session', as it were, will remain whether I start the script from cron 
every morning (say), or automatically from the /etc/rc[n].d directories.

Further, I don't seem to be able to *stop* socat without pressing ^C 
in the session, suggesting to me that cron won't be able to, either. 
I tested trying to stop socat, but from another session, to emulate 
what would happen if I used cron to start socat every morning (say) 
and also to stop it late at night; I used 2 terminal sessions to 
emulate cron giving the separate morning and night commands.  Here's 
what happened:

terminal-session-1 # service socat start
   <blank line, no prompt, socat is working at this point>

another-terminal-session-2 # service socat stop
   <another blank line, no prompt, but socat *continues* to run>
   < long wait >
   < eventually, ^C>

another-terminal-session-2 # <prompt reappears>

*also*, then on the first session,

Killed
terminal-session-1 # <the prompt reappears>

This test reveals that starting socat is fine, but only a user and 
actual process running socat can stop it and even then it has to get 
back into some kind of 'command' mode to do so.

[I was surprised that
# service socat stop
did not stop socat - the script (it is just debian's standard script) 
references the process by its pid which it determines using the line
PIDFILE=/var/run/$NAME.pid
(and NAME=socat)
but it still does not stop it.]

In principle, how should a system be configured so that something like 
socat can be started, and stopped?

regards, Ron

[toc] | [prev] | [next] | [standalone]

#182014

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

[toc] | [prev] | [next] | [standalone]

#182136

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.

[toc] | [prev] | [next] | [standalone]

#182162

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

On Tue, Jun 13, 2017 at 08:39:03AM -0400, Greg Wooledge wrote:
> 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 [...]

Agreed.

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

I think we are saying the same here (although your extra details are,
of course very informative).

[...]

> >   kill -INTR <pid>
> 
> Two mistakes here.
> 
> 1) It's -INT, not -INTR.

Yes. I obviously got confused with the stty naming :)

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

Right. As far as I remember, you can send the signal to all members
of a process group if you send it to the negative PID of the process
group leader.

[sysV style process mgmt]

> If you're a historian.  Otherwise, I wouldn't recommend reading these.
> They will warp your brain, and teach you bad habits.

I disagree. Know the downsides, use critically. I think I talked about
the downsides. If you *have* a process manager (systemd, runit, pies,
you name it), then use it. For small tasks, I still use the SysV scheme
(and for my usual init). I think I made that clear :)

We just seem to differ on "how bad" the classical scheme is: for me,
it's "sometimes good enough". But yes, know its downsides.

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

Thanks for the wiki entry!

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

iEYEARECAAYFAllAOYUACgkQBcgs9XrR2kbr/QCfXr0ls0lYVX2cMmXas9WUTHMs
pyAAn1j+iHuqsiCzqdIyr96lmObFeXuO
=GUnV
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web