2

I had a connection established between two processes:

netstat -tpn | grep 9999
tcp        0      0 127.0.0.1:*58728*         127.0.0.1:9999          ESTABLISHED 17366/*my_app.bin*

After killing this process,
1. The connection is still in ESTABLISHED state
2. I've noticed port 58728 is still in the netstat table, with another process name:

tcp        0      0 127.0.0.1:*58728*         127.0.0.1:9999          ESTABLISHED 19645/*udhcpc*

How could it be?

  • I would assume that the connection is not still there but again. Does the "new" process exist already when you kill the "old" one? Save the putput of ps -e -o pid,euser,time,etime,args before killing my_app.bin. The "new" process may have been waiting for the port to become free all the time. – Hauke Laging Aug 16 '17 at 21:42
  • Yes, it's exists before killing the process. It's kind of DHCP daemon. I'll try what you suggested. Thanks – hudac Aug 16 '17 at 22:01
  • Before killing your process you should be able to see with strace that the other one regularly tries to bind to this port. – Hauke Laging Aug 16 '17 at 22:16
  • @HaukeLaging ok, this is REALLY strange. When I did what you suggested ./strace /sbin/udhcpc -R --foreground -p /var/run/udhcpc.eth0.pid -i eth0 then udhcpc doesn't behaves the same! All ports that were before captured by udhcpc are now just tcp 0 0 127.0.0.1:48222 127.0.0.1:9999 TIME_WAIT - Which is what was supposed to happen in the first place! – hudac Aug 17 '17 at 8:30
  • Sorry, I wasn't accurate. When the udhcpc father is the init, then udhcpc always hijacks the released ports. When I start udhcpc with strace, or another intermediate app/script (so init isn't the father), the udhcpc doesn't/can't hijack the released ports. I don't understand: 1. What it this behaviour? 2. Why would udhcpc hijack ports? Is it malware or what? – hudac Aug 17 '17 at 12:46
1

Seems like the problem was the udhcpc process was spawned from my my_app.bin process.
In this spawn the spawned process inherites all the open file descriptors of my_app.bin. So when I close the socket from my_app.bin, it's not being closed from udhcpc.

Solutions:

  1. Use O_CLOEXEC when opening a socket, or fcntl() with FD_CLOEXEC flag later.
  2. In the spawed process, close all not-relevant open file descriptors.

In my case I don't control udhcpc, so I need to use option number 1.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.