I have written a socket-server like here. If I type ctrl+c in telnet, the server don't do anything now. I want to catch it like signal(SIGINT,SIG_IGN)
How can I do?
The telnet program catches the CTRL-C character and sends it as a single byte (\x03) down the TCP connection to the other side. It's up to the receiving program to decide what to do with that byte.
In the case of it being received by a "telnet daemon" intending to provide console-like interactivity via a pseudo-terminal, that combination generates a SIGINT to the process running under it, usually a shell.
So, to answer your question, you can either process the received \x03 character and internally generate a SIGINT or you can run your entire program as a process spawned and controlled by telnetd under a pseudo-terminal.
The telnet client (the process that recieves the SIGINT) should process it: either handle it locally (eg: terminate, or re-issue a prompt), or send it to the server as IAC something (BRK?) and/or out-of band data.
If you want to pass the interrupt to the server, Google for "telnet IAC" will probably get you started.
Related
I've set up a remote kernel running through SSH to which I connect using my Spyder IDE, and have just added 2-factor authentication (2FA) on the SSH connections using Duo .
Now when I attempt to connect, I get 4 different push notifications, and once I approve some or all of them, Spyder connects and gives me the IPython prompt; and for each attempt below I did approve all 4.
On my first attempt, it didn't display a result when testing with something like 2+2
On my second attempt, everything appeared to be working fine.
However, I am aware that there are 5 channels involved (shell, iopub, hb, stdin, control) as I can see on this Jupyter client doc page.
Is there any way I can, once connected to the remote kernel, test each of the individual 5 channels and check that they are all working properly?
And can you think of a reason why I would receive 4 push notifications rather than 5? Is it possible that one of the channels isn't used or connected to later on-demand or something like that?
UPDATE: After doing a netstat on the server side, I can see that the control channel is not connected, but the other four (shell, iopub, hb, stdin) are. Still unsure what I miss out on by not using the control channel, and whether Spyder provides the same features the control channel by other means; this page says:
Control: This channel is identical to Shell, but operates on a separate socket to avoid queueing behind execution requests. The control channel is used for shutdown and restart messages, as well as for debugging messages.
For a smoother user experience, we recommend running the control channel in a separate thread from the shell channel, so that e.g. shutdown or debug messages can be processed immediately without waiting for a long-running shell message to be finished processing (such as an expensive execute request).
Any idea why when I connect remotely (ssh session) to my Google Compute Engine instance, if I run a command (run an HTTP API) and leave, this one stops running as well?
./main PORT // Stops when I leave
./main PORT & // Stops when I leave as well..
No matter what, if I disconnect from my current ssh session, my API stops, even if the engine still seems to run fine
When you disconnect your terminal, all processes started by that terminal are sent a "hangup" signal which, by default, causes the process to terminate. You can trap the hangup signal when you launch a process at cause the signal to be silently ignored. The easiest way to achieve this is with the nohup command. For example:
nohup ./main PORT &
References:
What Is Nohup and How Do You Use It?
Unix Nohup: Run a Command or Shell-Script Even after You Logout
nohup(1) - Linux man page
I have some images in my queue and I pass each image to my flask server where processing on images is done and a response is received in my rabbitmq server. After receiving response, I get this error "pika.exceptions.StreamLostError: Stream connection lost(104,'Connection reset by peer')". This happens when rabbitmq channel again starts consuming the connection. I don't understand why this happens. Also I would like to restart the server again automatically if this error persists. Is there any way to do that?
Your consume process is probably taking too much time to complete and send Ack/Nack to the server. Therefore, server does not receive heartbeat from your client, and thereby stops from serving. Then, on the client side you receive:
pika.exceptions.StreamLostError: Stream connection lost(104,'Connection reset by peer')
You should see server logs as well. It is probably like this:
missed heartbeats from client, timeout: 60s
See this issue for mor information.
Do your work on another thread. See this code as an example -
https://github.com/pika/pika/blob/master/examples/basic_consumer_threaded.py
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
You can change stream connection limit if you set heartbeat in ConnectionParameters
connection_params = pika.ConnectionParameters(heartbeat=10)
wher number in seconds. It say yout TCP connection keepalive to 10 seconds for example.
More information https://www.rabbitmq.com/heartbeats.html and https://www.rabbitmq.com/heartbeats.html#tcp-keepalives
I am not pasting the source code here, if any one whats to reproduce the problem, download the code from this github project:
It is a Comet server, the server use libevent-2.0.21-stable http.
To reproduce the problem:
start the icomet-server from machine S
run curl http://ip:8100/stream from another machine C, the server S will show message that C has connected
if I press CTRL + C to terminate curl, the server knows that C is disconnected as expected.
if I pull out the network line from machine C(a physical network broken), the server will NOT know that C is disconnected, which it SHOULD know!
I will askany one who is familiar with libevent, how to make libevent 2 to detecting client network broken?
When the physical network link is interrupted, you won't always get a packet back to tell you that you lost the connection. If you want to find out about a disconnection, send a ping (a request that just asks for a no-op reply) periodically, and if the reply doesn't come within some reasonable timeout, assume something went wrong. Or just disconnect the client if they're idle for long enough.
When you did that Ctrl-C, the OS that the other end was running on was still working, and so it was able to generate a TCP RST packet to inform your server that the client has gone away. But when you break that physical link, the client is no longer capable of sending that cry for help. Something else has to infer that the client went away.
Now, if you try to send the client some data, the server kernel will notice (sooner or later) that the client is not replying to its messages. At this point you'll see the disconnect - but it may take several minutes for this to happen. If you're not sending any data, then it'll stay open until either you disconnect it, or the kernel attempts a TCP keepalive (a low-level way of the kernel asking "Hey, I haven't heard from you for a while, are you still there?") potentially hours later (or it might not even do a keepalive at all for you, depending on how things are configured).
I'm developing my own antimalware application. I have successfully implemented file system and process monitoring and now I'm looking for "some kind of firewall feature". I have already done some research and found iphlpapi.dll, netstat -o parsing.
Exactly, I would like to receive event with following data, when new IP (TCP/UDP/whatever) connection is opened.
Remote IP address
Protocol (TCP/UDP/...)
Port
ID of process which opened connection
I don't want to run timer which still checks netstat output, because it's not effective. I need to suspend process (I know how to suspend process) fastly, when connection to malicious IP is detected.
I suspect that besides writing a driver the only way to do this is Event Tracing for Windows (ETW). Check .NET System.Diagnostics.Eventing
About ETW https://msdn.microsoft.com/en-us/library/windows/desktop/aa363668(v=vs.85).aspx
In the ETW you can start from the following three providers:
Microsoft-Windows-NDIS-PacketCapture
Microsoft-Windows-TCPIP
Microsoft-Windows-Networking-Correlation