As of Go 1.21 syscall.Setrlimit and syscall.prlimit can affect
starting a new process, by restoring the original NOFILE rlimit.
That is recorded locally in the syscall package, so just always
call the syscall functions.
For golang/go#46279
Change-Id: I2f3dafe5562a7dde1297bad6f5d34a80af5d620b
Reviewed-on: https://go-review.googlesource.com/c/sys/+/476695
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The current code has continued to work on OpenBSD, since it has been using
syscall(2) via libc. However, the system call numbers are still hardcoded in
golang.org/x/sys/unix. Various system call changes have been made in OpenBSD,
resulting in changes to the system call numbers and arguments, which now
fail when this package is used.
Switch to calling various system calls directly via libc, rather than calling
via libc using syscall(2).
Unfortunately, this will no longer work on upstream Go since the changes
needed to convert it to libc are still blocked pending review. This means
that we're in a less than ideal situation where upstream Go openbsd/mips64
does not work on any supported OpenBSD release (in fact has not since
OpenBSD 6.8, which was EOL over a year ago), however golang.org/x/sys/unix
is now unusable with the Go package that ships with supported releases via
OpenBSD ports. It would seem that being able to actually use Go software on
a supported OpenBSD release trumps maintaining compatibility with the
unusable upstream Go source.
Updates golang/go#36435
Change-Id: Id8947cd0e4e05709e96c3d4478ac8789b924d416
Reviewed-on: https://go-review.googlesource.com/c/sys/+/459497
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Joel Sing