Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: Go 1.2 fails to build on Mac OS X 10.9.1 with modified /etc/launchd.conf #7381

Closed
gopherbot opened this issue Feb 21, 2014 · 6 comments

Comments

@gopherbot
Copy link

gopherbot commented Feb 21, 2014

by tim.olsen@10gen.com:

What steps will reproduce the problem?

1.  Modify /etc/launchd.conf to have the following contents:
limit maxfiles 20000 50000
2.  Reboot
3.  Try to compile Go from source:
$ hg clone -u release https://code.google.com/p/go
destination directory: go
requesting all changes
adding changesets
adding manifests
adding file changes
added 19187 changesets with 65911 changes to 8599 files (+7 heads)
updating to branch release-branch.go1.2
$ ./all.bash 
# Building C bootstrap tool.
cmd/dist

# Building compilers and Go bootstrap tool for host, darwin/amd64.
lib9
libbio
libmach
misc/pprof
cmd/addr2line
cmd/nm
cmd/objdump
cmd/pack
cmd/prof
cmd/cc
cmd/gc
cmd/6l
cmd/6a
cmd/6c
cmd/6g
pkg/runtime
pkg/errors
pkg/sync/atomic
pkg/sync
pkg/io
pkg/unicode
pkg/unicode/utf8
pkg/unicode/utf16
pkg/bytes
pkg/math
pkg/strings
pkg/strconv
pkg/bufio
pkg/sort
pkg/container/heap
pkg/encoding/base64
pkg/syscall
pkg/time
pkg/os
pkg/reflect
pkg/fmt
pkg/encoding
pkg/encoding/json
pkg/flag
pkg/path/filepath
pkg/path
pkg/io/ioutil
pkg/log
pkg/regexp/syntax
pkg/regexp
pkg/go/token
pkg/go/scanner
pkg/go/ast
pkg/go/parser
pkg/os/exec
pkg/os/signal
pkg/net/url
pkg/text/template/parse
pkg/text/template
pkg/go/doc
pkg/go/build
cmd/go

# Building packages and commands for darwin/amd64.
runtime
errors
sync/atomic
unicode
unicode/utf8
math
sort
encoding
unicode/utf16
crypto/subtle
sync
container/list
container/ring
image/color
runtime/race
container/heap
io
syscall
image/color/palette
hash
crypto/cipher
hash/crc32
crypto/hmac
hash/adler32
hash/crc64
hash/fnv
bytes
strings
text/tabwriter
bufio
time
path
html
compress/bzip2
strconv
math/rand
math/cmplx
os
crypto
reflect
encoding/base64
regexp/syntax
net/url
crypto/aes
crypto/rc4
crypto/md5
crypto/sha1
crypto/sha256
path/filepath
os/exec
encoding/pem
os/signal
crypto/sha512
encoding/ascii85
encoding/base32
image
io/ioutil
regexp
image/draw
image/jpeg
encoding/binary
fmt
debug/dwarf
crypto/des
index/suffixarray
flag
go/token
encoding/json
encoding/xml
text/template/parse
log
compress/flate
debug/elf
debug/macho
debug/pe
go/scanner
math/big
encoding/hex
go/ast
compress/gzip
mime
runtime/pprof
text/template
cmd/yacc
archive/tar
archive/zip
compress/lzw
compress/zlib
database/sql/driver
debug/gosym
crypto/elliptic
crypto/rand
crypto/dsa
encoding/asn1
database/sql
crypto/rsa
encoding/csv
go/parser
go/printer
go/doc
crypto/ecdsa
crypto/x509/pkix
encoding/gob
html/template
image/gif
image/png
runtime/debug
testing
cmd/cgo
go/format
go/build
cmd/gofmt
cmd/fix
testing/iotest
testing/quick
text/scanner
runtime/cgo
net
os/user
crypto/x509
net/textproto
log/syslog
mime/multipart
net/mail
crypto/tls
net/http
net/smtp
cmd/go
expvar
net/http/cgi
net/http/cookiejar
net/http/httptest
net/http/httputil
net/http/pprof
net/rpc
net/http/fcgi
net/rpc/jsonrpc

run.bash: line 20: ulimit: open files: cannot modify limit: Invalid argument


What is the expected output?
Successful compilation
@amerine
Copy link

amerine commented Feb 21, 2014

Comment 1:

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/

@davecheney
Copy link
Contributor

davecheney commented Feb 21, 2014

Comment 2:

@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.

@gopherbot
Copy link
Author

gopherbot commented Feb 21, 2014

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.

@rsc
Copy link
Contributor

rsc commented Feb 24, 2014

Comment 4:

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.

@rsc
Copy link
Contributor

rsc commented Feb 24, 2014

Comment 5:

This issue was closed by revision e6e8945.

Status changed to Fixed.

@gopherbot
Copy link
Author

gopherbot commented Feb 26, 2014

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 mikioh changed the title Go 1.2 fails to build on Mac OS X 10.9.1 with modified /etc/launchd.conf build: Go 1.2 fails to build on Mac OS X 10.9.1 with modified /etc/launchd.conf Jan 15, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants