On Thu, 2010-08-19 at 16:22 -0400, Jerry Geis wrote:

Jerry Geis wrote:

...

I have coded up the standard sendfd() and recvfd() for linux to send and recv file descriptors. seems to work (http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch17l...)

however when I recvfd() my number of open file descriptors bumps by 2 and not 1. (using lsof -p X | wc -l)

I am not sure why the count jumps by 2 and not 1. The sendfd() is just sending a socket descriptor. If I close() the provided descriptor it only closes 1 handle (again using lsof above).

So my recvfd() is giving me 2 but when I close() I only drop 1 and not 2. Something is not in alignment and just wondering if someone can shed some light on this. Thanks.

Jerry

Here is a diff of the lsof output when a new connection is made and the old connection is closed. The lingering /dev/null is evident. I dont know where that is from nor why it does not close upon calling close().

Jerry

13d12 < kendra 13162 root 4u IPv4 999539 TCP devcentos5x64.msgnet.com:6520->am2mm.msgnet.com:52047 (ESTABLISHED)

...

kendra 13162 root 61u IPv4 999634 TCP

devcentos5x64.msgnet.com:6520->am2mm.msgnet.com:60390 (ESTABLISHED) 73a74

...

kendra 13162 root 66r CHR 1,3 1749

/dev/null

--- You passing data or what?

You can also do by "lsof -a -p 0000" "wc" skips things in lsof, you want every descriptor open and cat /proc/${PID}/fd/ To make sure. lsof -i @x.x.x.x for active connections or remaining dead

Passing data to disk fsync() first then close()?

Ahh I read the page you linked and according to it in a client server like arch the server descriptor will stay open....

"""Closing the descriptor by the sender doesn't really close the file or device, since the descriptor is still considered open by the receiving process (even if the receiver hasn't specifically received the descriptor yet)."""

Kinda what I thought.

ohn