fdlimit: improve fdlimit autoraising tests

[whyrusleeping]

Better tests for this, at least on linux we can check it externally. I don't know of a good way to do this on OSX

[Kubuxu]

LGTM

@jbenet do you want to also give it a review?

[jbenet]

• this is nice
• but we really need to also test in osx. and we shouldn't trust what the limits say, should test for sure that we can indeed open that many fds.
• http://stackoverflow.com/questions/31115764/setrlimit-doesnt-work-on-os-x-maverick-and-yosemite
  • setrlimit may not work on osx, and many times osx reports incorrect fd limits
• we can test things for real (in both osx and linux) with a tool like open-fds <fds> <multiaddr> which uses nc to hang fds open.
  • then count the fds with lsof. maybe: lsof -p $1 | grep -v " txt " | wc -l
  • then kill the open-fds process.

[Kubuxu]

The open-fds process would have to start from go-ipfs process, to inherit the fd limit.
Otherwise we are testing nothing.

Other approach would be to make the fd rising separate package, produce a small binary that tries opening files with and without the fd limit raised.

[whyrusleeping]

"this is nice"

[jbenet]

Made this for you https://github.com/jbenet/hang-fds

[jbenet]

I'm using syscall.Setrlimit in https://github.com/jbenet/hang-fds/blob/master/hang-fds.go#L32-L63

> ulimit -Sn 256
> ulimit -Sn
256
> ./hang-fds 2048 /ip4/127.0.0.1/tcp/1234
hanging 2048 fds at /ip4/127.0.0.1/tcp/1234
error: failed to raise fd limit to 2058 (still 256)

[whyrusleeping]

@jbenet you never actually change the fd limit in that code. you call getrlimit, you check the value, and then you you call setrlimit with the same object.