sockets are files, everything is a file, whatever just use the rm command On Fri, Jan 23, 2015 at 7:24 PM, Jason E. Aten <j.e.aten@xxxxxxxxx> wrote: > On linux, looking in /proc/PID/fd, it looks the leaked fd are eventfd. > > from /proc > lr-x------ 1 vagrant vagrant 64 Jan 24 00:13 0 -> /dev/null > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 1 -> /dev/pts/5 > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 10 -> socket:[170235] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 11 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 12 -> socket:[173591] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 13 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 14 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 15 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 16 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 17 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 18 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 19 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 2 -> /dev/pts/5 > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 20 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 21 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 22 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 23 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 3 -> /dev/tty > lr-x------ 1 vagrant vagrant 64 Jan 24 00:13 4 -> /dev/urandom > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 5 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 6 -> anon_inode:[eventpoll] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 7 -> anon_inode:[eventfd] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 8 -> socket:[173551] > lrwx------ 1 vagrant vagrant 64 Jan 24 00:13 9 -> anon_inode:[eventpoll] > vagrant@precise64:/proc/15001/fd$ > > > On Fri, Jan 23, 2015 at 3:20 PM, Jason E. Aten <j.e.aten@xxxxxxxxx> wrote: > >> Does anyone have tips or tricks for tracking down leaking file >> descriptors? According to lsof, they appear to be pipes (OSX) and >> "anonymous inodes" (Linux). Any suggestions? I'm at a loss. >> >> Details: I'm using push/pull nanomsg (updated yesterday; most recent from >> github) sockets between a client and a server. It looks like every client >> connection to the server results in the server leaking more file >> descriptors. On OSX, I see pipes left open. condensed "lsof -p 34334 -Fnt" >> output shows these are leaked (OSX): >> >> tPIPE:n->0x95df5be7a4700aff >> >> tPIPE:n->0x95df5be7a46fee1f >> >> tPIPE:n->0x95df5be79ddeb75f >> >> tPIPE:n->0x95df5be7a16570df >> >> tPIPE:n->0x95df5be7a165702f >> >> tPIPE:n->0x95df5be79ddeae6f >> >> tPIPE:n->0x95df5be7a47006df >> >> tPIPE:n->0x95df5be7ada5a0ff >> >> tPIPE:n->0x95df5be7a165912f >> >> tPIPE:n->0x95df5be7a46ff0df >> >> tPIPE:n->0x95df5be7ac4c2ecf >> >> tPIPE:n->0x95df5be7ac4c499f >> >> tPIPE:n->0x95df5be7a470041f >> >> tPIPE:n->0x95df5be7ac4c554f >> >> tPIPE:n->0x95df5be7a46ffbdf >> >> tPIPE:n->0x95df5be7a46ff39f >> >> tPIPE:n->0x95df5be7a46fe94f >> >> tPIPE:n->0x95df5be7a165a1af >> >> tPIPE:n->0x95df5be7a470057f >> >> tPIPE:n->0x95df5be7a46fe68f >> >> On Linux it is anonymous inodes that are leaking. Output from "lsof -p >> 2332 -Fnt": >> >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> t0000:nanon_inode >> >> >> > > > -- > > Best regards, > Jason > > -- > Jason E. Aten, Ph.D. > j.e.aten@xxxxxxxxx > 650-429-8602 > linkedin: https://www.linkedin.com/pub/jason-e-aten-ph-d/18/313/45a > -- Bent Cardan nothingsatisfies.com | bent@xxxxxxxxxxxxxxxxxxxx