On Sat, Mar 28, 2020 at 8:07 AM W. Michael Petullo <[email protected]> wrote: > > I am playing with Go and setrlimit(). Here is some code from a test that > executes after setting RLIMIT_NPROC to 0: > > err = exec.Command("true").Run() > if e, ok := err.(*os.PathError); !ok || e.Err.(unix.Errno) != unix.EAGAIN { > t.Error(err.Error()) > } > > /* Test succeeded: Run failed with EAGAIN as the process (thread) limit is > exceeded. */ > > This seems to work, but I am surprised that Run() returns an os.PathError > rather than an os.SyscallError. I would expect EAGAIN to be the latter. > > Is this intentional? I guess I am looking for the reason for this so tha t my > min d can more easily remember it.
Yes, it's intentional. For this case exec.Command.Run just returns the error from os.StartProcess, which is documented to consistently return an error of type *os.PathError. StartProcess returns PathError so that it can return the name of the executable that was not started. It's true that in some cases it would be better to return SyscallError, although that would require some work to keep track of exactly which system call failed: it might easily be a system call executed by the child process. But I'm not sure we can change it now, given that it has worked this way for a long time and it is documented. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWuKtg4Amvi3jESiQxF9kXTSf7q801t0zA3K9VP%2BL4K%3DA%40mail.gmail.com.
