code review 6453154: run.bash: set appropriate ulimits

run.bash: set appropriate ulimits
    mainly for NetBSD/OpenBSD.

[minux1, 2012-08-20 12:34:28]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[bradfitz, 2012-08-20 13:23:41]

This feels wrong.

Why would you want to lower if it's already higher?

And if it's lower, you won't have permission to raise it, unless you're
root.

e.g.
ba12:~ bradfitz$ ulimit -n
2560
ba12:~ bradfitz$ ulimit -n 5
ba12:~ bradfitz$ ulimit -n 6
-bash: ulimit: open files: cannot modify limit: Operation not permitted


On Mon, Aug 20, 2012 at 10:34 PM, <minux.ma@gmail.com> wrote:

> Reviewers: golang-dev_googlegroups.com,
>
> Message:
> Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),
>
> I'd like you to review this change to
> https://code.google.com/p/go/
>
>
> Description:
> run.bash: set appropriate ulimits
>     mainly for NetBSD/OpenBSD.
>
> Please review this at
http://codereview.appspot.com/**6453154/<http://codereview.appspot.com/6453154/>
>
> Affected files:
>   M src/run.bash
>
>
> Index: src/run.bash
> ==============================**==============================**=======
> --- a/src/run.bash
> +++ b/src/run.bash
> @@ -14,6 +14,11 @@
>  # no core files, please
>  ulimit -c 0
>
> +# we need at least 256 open files (for NetBSD/OpenBSD)
> +ulimit -n 256
> +# raise data limit on NetBSD, as test/nilptr.go needs ~300MB of bss
> +ulimit -d 524288
> +
>  # allow all.bash to avoid double-build of everything
>  rebuild=true
>  if [ "$1" = "--no-rebuild" ]; then
>
>
>

[minux1, 2012-08-20 13:37:13]

On Mon, Aug 20, 2012 at 9:23 PM, Brad Fitzpatrick <bradfitz@golang.org>wrote:

> Why would you want to lower if it's already higher?
>
> And if it's lower, you won't have permission to raise it, unless you're
> root.
>
> e.g.
> ba12:~ bradfitz$ ulimit -n
> 2560
> ba12:~ bradfitz$ ulimit -n 5
> ba12:~ bradfitz$ ulimit -n 6
> -bash: ulimit: open files: cannot modify limit: Operation not permitted
>
but this ulimit runs in its own subshell, it won't affect your environment.
and i think it can also help catching leaking fd in tests (besides relieving
user from reading respective go-wiki article before running ./all.bash)

(of course, i assume nobody run ". run.bash", it's just unreasonable, and
will surely cause other problems, for example, we "set -e" in run.bash)

if it is acceptable, i think we can add OS specific checks to make.bash
also.
for example, we need rthread on OpenBSD.

[minux1, 2012-08-27 20:02:05]

ping?

[r, 2012-08-27 20:12:48]

http://codereview.appspot.com/6453154/diff/1003/src/run.bash
File src/run.bash (right):

http://codereview.appspot.com/6453154/diff/1003/src/run.bash#newcode20
src/run.bash:20: ulimit -d 524288
these changes are for netbsd, but are set globally. it still feels wrong.

[minux1, 2012-08-28 08:15:29]

On Tue, Aug 28, 2012 at 4:12 AM, <r@golang.org> wrote:
>
>
http://codereview.appspot.com/**6453154/diff/1003/src/run.**bash#newcode20<ht...
> src/run.bash:20: ulimit -d 524288
> these changes are for netbsd, but are set globally. it still feels
> wrong.
>
How about we do this:
ulimit -S -d $(ulimit -H -d)

it's only a best effort setting, and it will have minimum impact on
existing systems.

[rsc, 2012-08-31 16:05:35]

http://codereview.appspot.com/6453154/diff/12001/src/run.bash
File src/run.bash (right):

http://codereview.appspot.com/6453154/diff/12001/src/run.bash#newcode18
src/run.bash:18: [ "$(ulimit -H -n)" != "unlimited" ] && ulimit -S -n $(ulimit
-H -n)
You can't use x && y unless x is always true. If x is false, the set -e above
should make the script exit. You can use !x || y.

But I don't understand this logic either. Why not just

# Raise soft limits to hard limits on NetBSD/OpenBSD.
# We need at least 256 files and ~300 MB of bss.
ulimit -S -n $(ulimit -H -n)
ulimit -S -d $(ulimit -H -d)

[minux1, 2012-09-01 08:29:56]

On Sat, Sep 1, 2012 at 12:05 AM, <rsc@golang.org> wrote:

> http://codereview.appspot.com/**6453154/diff/12001/src/run.**
>
bash#newcode18<http://codereview.appspot.com/6453154/diff/12001/src/run.bash#newcode18>
> src/run.bash:18: [ "$(ulimit -H -n)" != "unlimited" ] && ulimit -S -n
> $(ulimit -H -n)
> You can't use x && y unless x is always true. If x is false, the set -e
> above should make the script exit. You can use !x || y.
>
strange, this script runs to completion:
#!/bin/bash
set -e
a="B"
[ $a ==  "A" ] && echo a is A
echo status=$?
echo done

>
> But I don't understand this logic either. Why not just
>
On Mac OS X 10.6.8 at least, this command:
ulimit -S -n $(ulimit -H -n)
fails with: -bash: ulimit: open files: cannot modify limit: Invalid argument
because $(ulimit -H -n) is "unlimited".

[rsc, 2012-09-01 13:58:47]

It must be yet another strange inconsistent corner of bash and set -e.
It might still be nice to avoid.

How about this?

# Raise soft limits to hard limits for NetBSD/OpenBSD.
# We need at least 256 files and ~300 MB of bss.
# On OS X ulimit -S rejects 'unlimited'.
[ "$(ulimit -H -n)" == "unlimited" ] || ulimit -S -n $(ulimit -H -n)
[ "$(ulimit -H -d)" == "unlimited" ] || ulimit -S -n $(ulimit -H -d)

[minux1, 2012-09-02 19:08:11]

PTAL.

[rsc, 2012-09-10 15:40:46]

LGTM

[minux1, 2012-09-16 17:11:41]

*** Submitted as http://code.google.com/p/go/source/detail?r=a97b81d2600f ***

run.bash: set appropriate ulimits
    mainly for NetBSD/OpenBSD.

R=bradfitz, r, rsc
CC=golang-dev
http://codereview.appspot.com/6453154