Is it possible to kill a process on a port from within the program, when the program is terminated?
Related
I have a linux computer (super small low powered, similar to raspberry pi) that is running zerotier. I can ping this from the outside and this computer has access to an internal server. What I am trying to do is to send wake on lan packets to the zerotier computer and have this forward the packet to 192.168.1.5.
The purpose of this is that the server is also running zerotier and I can access it from the outside, but when the server is shut down there is no way to reach it from the outside. I am therefore trying to use this linux computer to forward the wake on lan packets so that I can boot the server remotely.
For my case it would be enough to simply ssh into the linux computer and send the wake on lan from there, but sometimes my wife need to boot the server and I doubt I can teach her any time soon how to ssh into the linux computer and send a WoL from command line. Therefore I need the linux computer to forward the wake on lan to the internal ip. How can I do this?
A few tutorials, including this Learn You Some Erlang one, show applications where an OTP supervisor will open and own a TCP listen socket and share it to a number of workers, who will accept connections.
My question is, how do you close a listen socket owned by a supervisor without a terminate/2 callback function?
The socket is linked to the process that owns it. If that process exits, the socket is automatically closed. (This goes for both listening sockets and connection sockets.)
(The process that owns the socket is the process that created it, unless you've called gen_tcp:controlling_process to reassign ownership of the socket.)
Let say I have two processes, both are listening on the port 80 (html) awaiting for an html packet to be unpacked, analyzed and displayed.
Now how does the system know which process is the html packet for ?
For instance, It seems Skype is listening on the port 80 while another application does too. How does Skype know "this packet is for me ?" and on which network layer that process is happening ?
You can "reuse" a port. When application crashes or exits not closing a socket the system can see the port as still "used", so with this feature you can actually reuse it again. As I know if multiple sockets are listening on the same port, packets will be delivered to them in pseudo-random manner. I don't know if this can be used reliably.
Also port is not a unique system-wide thing, only "port + IP address" is. So multiple applications can safely use the same port if they are bound to different network interfaces.
Sometimes when my application exits, the UDP port it listens on cannot be reused. The only solution is it reboot the machine before restarting the application.
Netstat doesn't show any applications using the UDP port.
>netstat -apn | grep 9988
udp 0 0.0.0.0:9988 0.0.0.0:*
I am using Qt's QUdpSocket class.
I am running mpirun (Open MPI) 1.8.5 on my Mac OSX 10.9, but when I try
mpirun -np 4 run.exe
the terminal just hangs and eventually I get an error message
A process or daemon was unable to complete a TCP connection
to another process:
Local host: my_computer_name
Remote host: 10.0.0.15
This is usually caused by a firewall on the remote host. Please
check that any firewall (e.g., iptables) has been disabled and
try again.
Now, if I turn off my Wifi, everything works fine. Also, I do not have any firewall enabled. It's really annoying to have to turn off my wifi everytime I need to run mpi. Any ideas?
See this question and its answers. You need to tell MPI explicitely not to use the wifi, then it will survive disabling the wifi.
What happens is, that MPI greedily uses all IP networks it can muster,
thus, when you disable wifi, MPI looses one of the IP connections it uses.