search

ralphlange / procServ

Wrapper to start arbitrary interactive commands in the background, with telnet or Unix domain socket access to stdin/stdout
GNU General Public License v3.0
23 stars 23 forks source link

Telnet connection #47

Closed G109B closed 3 years ago

G109B commented 3 years ago

procserv is running a program which requires no input. I can obtain its output stream using 'telnet localhost port' no problem. However 'telnet localhost port </dev/null' gets chucked off with "connection closed by foreign host". Is there an option to prevent this ? Why do I ask ? Because I want to leave it running after I log off, and all of the usual suspects hit this snag.

ralphlange commented 3 years ago

Just close the connection. Your telnet connection goes to the procServ server, not to the program itself. If you disconnect, procServ will continue to run your program in the background, that's the whole point of procServ. Whenever you are back on your system, just telnet to the procServ port and you will be connected to your program again.

G109B commented 3 years ago

Thanks Ralph for your rapid reply. I haven't described my problem very well, so here is another attempt: The program running under procserv is part of a package which communicates with an APRS server, potentially for ever. The author runs it under procserv so that the program's input and output can be observed by connecting to a specific port, typically by telnet. I want to pipe this stream of text into a perl program, and this is successful in the foreground. eg: telnet localhost 1234 | myprog.pl (actually, but not necessarily, held in a script file). I have tried many ways of running this permanently (nohup, &, etc.) but they all quit immediately with the message "Connection closed by foreign host", which I am assuming is procserv objecting to stdin being closed. Am I correct, or am I missing something obvious ?

anjohnson commented 3 years ago

You probably should be using something other than telnet for that then, such as nc (netcat), or bash does TCP socket redirection (so in bash you would run myprog.pl < /dev/tcp/localhost/1234). Personally I would probably have the Perl script open its own TCP connection to the procServ port instead of reading stdin.

ralphlange commented 3 years ago

Understood. Have you tried using the logging port? That's the intended way to connect read-only to the program running under procServ.

G109B commented 3 years ago

You probably should be using something other than telnet for that then, such as nc (netcat), or bash does TCP socket redirection (so in bash you would run myprog.pl < /dev/tcp/localhost/1234). Personally I would probably have the Perl script open its own TCP connection to the procServ port instead of reading stdin.

/dev/tcp/localhost/port was a huge gap in my knowledge, and appears to solve the problem. Many thanks for that.

G109B commented 3 years ago

Understood. Have you tried using the logging port? That's the intended way to connect read-only to the program running under procServ.

Thanks again Ralph, I guess '-l newport' is an option I had missed, although it would involve some changes to scripts which come with the package.

G109B commented 3 years ago

Many thanks for your help Ralph and Andrew, I went with reading TCP direct from Perl (another gap in my knowledge) and it is working perfectly. Surprisingly easy to implement too.