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

os: there is no procfs on OpenBSD #19453

Closed
darinkes opened this issue Mar 8, 2017 · 9 comments
Closed

os: there is no procfs on OpenBSD #19453

darinkes opened this issue Mar 8, 2017 · 9 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-OpenBSD
Milestone

Comments

@darinkes
Copy link

darinkes commented Mar 8, 2017

What version of Go are you using (go version)?

go version go1.8 openbsd/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="openbsd"
GOOS="openbsd"
GOPATH="/home/srinkes/go_work/"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/openbsd_amd64"
GCCGO="gccgo"
CC="cc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="c++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

Compiled and started gitlab-ci-multi-runner on openbsd/amd64.
On startup I see this Warning:

WARN[0000] readlink /proc/curproc/file: no such file or directory

Apparently go tries to Readlink /proc/curproc/file in https://github.com/golang/go/blob/master/src/os/executable_procfs.go#L26

But there is no (optional) procfs on OpenBSD anymore. mount_procfs(8) was shipped last time with OpenBSD 5.5:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/mount_procfs/

  2 years ago:
  Delete procfs; it's always had races and is now unused: no one noticed for month...
@darinkes
Copy link
Author

darinkes commented Mar 8, 2017

Ok, in my case it seems its not coming from go core, but from https://github.com/kardianos/osext/blob/master/osext_procfs.go

Which also had nearly the same code as in go core:

        case "openbsd", "dragonfly":
                return os.Readlink("/proc/curproc/file")

But this was removed with this commit:
kardianos/osext@b4814f4

Maybe go core should do the same thing?

@darinkes
Copy link
Author

darinkes commented Mar 8, 2017

And with this commit it uses the core executable(). So an update of osext won't fix this if you want to use go 1.8:
kardianos/osext@9b883c5

@bradfitz bradfitz changed the title there is no procfs on OpenBSD os: there is no procfs on OpenBSD Mar 8, 2017
@bradfitz bradfitz added NeedsFix The path to resolution is known, but the work has not been done. OS-OpenBSD labels Mar 8, 2017
@bradfitz bradfitz added this to the Go1.9 milestone Mar 8, 2017
@bradfitz
Copy link
Contributor

bradfitz commented Mar 8, 2017

/cc @mdempsky

@mdempsky
Copy link
Member

mdempsky commented Mar 8, 2017

The report is correct: there's no procfs on OpenBSD. But unfortunately, there's also no alternative kernel API for implementing os.Executable. (This has a long contentious history within OpenBSD.)

So at best we can emit a better "not implemented" error instead of complaining that /proc doesn't exist.

Or we can try looking for os.Argv[0] in $PATH, and hope it's right. (I believe this is what apps ported to OpenBSD usually do when trying to port this functionality.)

@ianlancetaylor
Copy link
Contributor

CC @minux

@darinkes
Copy link
Author

darinkes commented Mar 9, 2017

As mentioned kardianos/osext has an workaround for this problem from an OpenBSD Developer: kardianos/osext@b4814f4

Maybe this can be included in go core?
(I have no opinion if this is a bad or good workaround)

CC @ajacoutot

@ajacoutot
Copy link

What I implemented in osext is not a workaround per se; as mentioned it's a "best effort" :-)
As @mdempsky said, the history behind implementing such a functionality in OpenBSD has been complex... and I wouldn't expect it to change.
The result is that apps implement it themselves which is why I think it'd make sense to have something in go core if possible.

orangemi pushed a commit to orangemi/gitlab-ci-multi-runner that referenced this issue May 27, 2017
@bradfitz
Copy link
Contributor

bradfitz commented Jun 7, 2017

@ianlancetaylor will copy the gccgo AIX code for argv[0] into std for openbsd.

And then enable the test:

func TestExecutable(t *testing.T) {
        testenv.MustHaveExec(t) // will also execlude nacl, which doesn't support Executable anyway                                                        
        ep, err := os.Executable()
        if err != nil {
                switch goos := runtime.GOOS; goos {
                case "openbsd": // procfs is not mounted by default                                                                                        
                        t.Skipf("Executable failed on %s: %v, expected", goos, err)
                }

We have OpenBSD trybots.

@gopherbot
Copy link

CL https://golang.org/cl/46004 mentions this issue.

gopherbot pushed a commit that referenced this issue Jun 22, 2017
On OpenBSD, Executable relies on Args[0].  Removing the forgery on
that OS allows the rest of the test to run.

See #19453

Change-Id: Idf99f86894de5c702893791bc3684f8665f4019d
Reviewed-on: https://go-review.googlesource.com/46398
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
xenoscopic added a commit to mutagen-io/mutagen that referenced this issue Jul 25, 2017
It seems that someone else finally caught onto the fact that the OpenBSD
mechanism was broken in the os package's implementation:

kardianos/osext#22
golang/go#19453

A fix will be available in Go 1.9, and in the mean time the osext
package has been updated to use its old method. Once 1.9 rolls out,
we'll get rid of the osext dependency.
@golang golang locked and limited conversation to collaborators Jun 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-OpenBSD
Projects
None yet
Development

No branches or pull requests

6 participants