build: Go 1.2 fails to build on Mac OS X 10.9.1 with modified /etc/launchd.conf #7381
Labels
Comments
I can replicate this on my machine (same version as Tim). I proposed a change in May '13 to fix this. https://golang.org/cl/9324044/ |
@tim Thank you for raising this issue. As I understand it, if a user changes their limits setting in launchd this will cause the go build to fail for a minor technical reason. My first thought is, "well, don't do that" as our CI builders have executed tens of thousands of successful builds without having to touch the launchd limits. If you could give more background on why you need to change your launchd limits this will help people looking at this issue understand the reasons for it, rather than just reacting superficially, as I did initially. Cheers Dave Labels changed: added release-none, repo-main, os-macosx. Status changed to WaitingForReply. |
|
Comment 3 by tim.olsen@10gen.com: Hi Dave. I needed to increase my maximum number of open file descriptors for development with MongoDB. Otherwise I run out of file descriptors. I do not think this is abnormal usage of MongoDB as MongoDB recommends increasing the limit. |
I believe the problem is that the hard limit for your process is actually higher than it can possibly be set by a non-root user. So trying to set it that high with ulimit -S -n fails. My guess is that if you run ulimit -S -n ulimit -H -n sysctl -a|grep kern.maxfiles you will find that the -H -n number is set to kern.maxfiles and is higher than kern.maxfilesperproc. Being higher than kern.maxfilesperproc sets up the situation where ulimit -S -n $(ulimit -H -n) fails: the hard limit is unachievable by an ordinary process. I would argue you have misconfigured your system. Whatever kern.maxfilesperproc says, that should be the hard limit you put in launchd.conf (or vice versa, you should change the kern.maxfilesperproc to allow what you are setting in launchd.conf). I don't want to do the CL 9324044 workaround, because what will happen on some systems is that ulimit -S is too small, ulimit -H is unachievably high, we ignore the failure to change -S, and then a test breaks later. I'd rather stop the build early. I will add a comment to run.bash with a brief explanation and pointing at this issue, so that if someone else runs into this they can find this discussion instead of having to debug the probem anew. Status changed to WorkingAsIntended. |
|
This issue was closed by revision e6e8945. Status changed to Fixed. |
|
Comment 6 by tim.olsen@10gen.com: Thanks for the diagnosis. I have no problem changing my kern.maxfilesperproc as a workaround. But I wonder, what is the point of kern.maxfilesperproc if it cannot be set to a number lower than the hard limit without it being considered misconfigured? If I set to a setting higher than the hard limit, then I assume the hard limit prevails. In which case, the only properly configured setting for kern.maxfilesperproc is the hard limit which makes the setting redundant. |
mikioh
changed the title
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by tim.olsen@10gen.com:
The text was updated successfully, but these errors were encountered: