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?

6
  • 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. Aug 16, 2017 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, 2017 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. Aug 16, 2017 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, 2017 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, 2017 at 12:46

1 Answer 1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .