14

My purspose was to set ulimit -n from within a golang program so that I do not have to set it globally but restrict it within the program.

Found systemcalls setrlimit and get rlimit for the same. (http://linux.die.net/man/2/setrlimit)

But when I tried a sample program for the same I was getting an error saying invalid argument while setting the value.

package main

import (
    "fmt"
    "syscall"
)

func main() {
    var rLimit syscall.Rlimit

    err := syscall.Getrlimit(syscall.RLIMIT_NOFILE, &rLimit)

    if err != nil {
        fmt.Println("Error Getting Rlimit ", err)
    }
    fmt.Println(rLimit)

    rLimit.Max = 999999
    rLimit.Cur = 999999

    err = syscall.Setrlimit(syscall.RLIMIT_NOFILE, &rLimit)
    if err != nil {
        fmt.Println("Error Setting Rlimit ", err)
    }

    err = syscall.Getrlimit(syscall.RLIMIT_NOFILE, &rLimit)
    if err != nil {
        fmt.Println("Error Getting Rlimit ", err)
    }
    fmt.Println("Rlimit Final", rLimit)
}

The output obtained was:

george@george-Not-Specified ~/work/odesk/progium/trial $ ./getRlimit 
{4294963002032703 0}
Error Setting Rlimit  invalid argument
Rlimit Final {4294963002032703 999999}
george@george-Not-Specified ~/work/odesk/progium/trial $ sudo ./getRlimit 
[sudo] password for george: 
{4294963002032703 0}
Error Setting Rlimit  invalid argument 
Rlimit Final {4294963002032703 999999}
george@george-Not-Specified ~/work/odesk/progium/trial $ uname -a
Linux george-Not-Specified 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 i686 i686 GNU/Linux
george@george-Not-Specified ~/work/odesk/progium/trial $ 

So I was able to get the rlimit Setting the limit failed and returned an error. Even though it failed the MAX value got changed when I took the value again but CUR value remains the same. Can this error be due to some issue with my kernel or is it a bad program? Where can I find more information and how to deal with an issue like this?

Update:

Works after the fix has been made.

george@george-Not-Specified ~/work/odesk/progium/trial $ go build getRlimit.go 
george@george-Not-Specified ~/work/odesk/progium/trial $ ./getRlimit 
{1024 4096}
Error Setting Rlimit  operation not permitted
Rlimit Final {1024 4096}
george@george-Not-Specified ~/work/odesk/progium/trial $ sudo ./getRlimit                                                                                               
[sudo] password for george: 
{1024 4096}
Rlimit Final {999999 999999}
george@george-Not-Specified ~/work/odesk/progium/trial $ uname -a
Linux george-Not-Specified 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012    i686 i686 i686 GNU/Linux
george@george-Not-Specified ~/work/odesk/progium/trial $ go version
go version devel +7c42cfa28e24 Tue Jul 30 14:22:14 2013 +1000 linux/386
mraron
  • 2,411
  • 18
  • 27
George Thomas
  • 1,246
  • 2
  • 11
  • 14

1 Answers1

33

It works as expected.

setrlimit(2).

The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process (under Linux: one with the CAP_SYS_RESOURCE capability) may make arbitrary changes to either limit value.

rlimit.go:

package main

import (
    "fmt"
    "syscall"
)

func main() {
    var rLimit syscall.Rlimit
    err := syscall.Getrlimit(syscall.RLIMIT_NOFILE, &rLimit)
    if err != nil {
        fmt.Println("Error Getting Rlimit ", err)
    }
    fmt.Println(rLimit)
    rLimit.Max = 999999
    rLimit.Cur = 999999
    err = syscall.Setrlimit(syscall.RLIMIT_NOFILE, &rLimit)
    if err != nil {
        fmt.Println("Error Setting Rlimit ", err)
    }
    err = syscall.Getrlimit(syscall.RLIMIT_NOFILE, &rLimit)
    if err != nil {
        fmt.Println("Error Getting Rlimit ", err)
    }
    fmt.Println("Rlimit Final", rLimit)
}

Output:

$ uname -a
Linux peterSO 3.8.0-26-generic #38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ go build rlimit.go
$ ./rlimit
{1024 4096}
Error Setting Rlimit  operation not permitted
Rlimit Final {1024 4096}
$ sudo ./rlimit
[sudo] password for peterSO:
{1024 4096}
Rlimit Final {999999 999999}

UPDATE:

I successfully ran rlimit.go for linux/amd64, you failed for linux/386. There were a Go bugs in Getrlimit and Setrlimit for Linux 32-bit distributions. These bugs have been fixed.

Using the Go default branch tip (to include the bug fixes), run the following, and update your question with the results.

$ uname -a
Linux peterSO 3.8.0-26-generic #38-Ubuntu SMP Mon Jun 17 21:46:08 UTC 2013 i686 i686 i686 GNU/Linux
$ go version
go version devel +ba52f6399462 Thu Jul 25 09:56:06 2013 -0400 linux/386
$ ulimit -Sn
1024
$ ulimit -Hn
4096
$ go build rlimit.go
$ ./rlimit
{1024 4096}
Error Setting Rlimit  operation not permitted
Rlimit Final {1024 4096}
$ sudo ./rlimit
[sudo] password for peterSO: 
{1024 4096}
Rlimit Final {999999 999999}
$ 
peterSO
  • 158,998
  • 31
  • 281
  • 276
  • @GeorgeThomas As PeterSO indicated: are you running the application with super-user privileges? – elithrar Jul 24 '13 at 04:06
  • @GeorgeThomas: Yes. Your `uname` output says `i686`, mine says `x86_64`. I have to set up a 32-bit virtual machine to finish debugging. – peterSO Jul 24 '13 at 07:28
  • I was also wondering about the value of current. ulimit -n returns 999999 but this is different. – George Thomas Jul 24 '13 at 12:41
  • @GeorgeThomas: It's a Go linux/386 bug. I'm working on a fix. – peterSO Jul 24 '13 at 18:01
  • @GeorgeThomas: See my updated answer. I've fixed some linux/386 Go bugs. – peterSO Jul 25 '13 at 14:29
  • @peterSO Thank you I tested with the latest branch and it works. – George Thomas Jul 31 '13 at 07:56
  • I had to `rLimit.Cur = rLimit.Max` (i.e could not change hard limit, and set soft limit to maximum of hard limit) for it to actually work in a real app, otherwise I got `operation not permitted` – Erik Rothoff Jun 22 '16 at 11:07
  • Its funny how this is still a problem, I am trying to get rid of the Invalid argument, which is effectively an un handled state. any solutions to this as yet? – Cyberience Feb 11 '20 at 02:57
  • I had this problem for my gofindpi package that checks a whole bunch of IP4 addresses and socket opens up a lot of virtual file locations, thus needing to up the default of 256 usually (at least on mac os) to something higher and reasonable. This was the only thing that worked for me as opposed to trying to do `exec.Command("ulimit", "-Sn", "2000")` or similar. – james-see May 08 '21 at 20:27