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

darinkes opened this issue Mar 8, 2017 · 9 comments

os: there is no procfs on OpenBSD #19453

darinkes opened this issue Mar 8, 2017 · 9 comments


Copy link

@darinkes 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)?

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"

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

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

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

@darinkes darinkes commented Mar 8, 2017

Ok, in my case it seems its not coming from go core, but from

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:

Maybe go core should do the same thing?

Copy link

@darinkes 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:

@bradfitz bradfitz changed the title there is no procfs on OpenBSD os: there is no procfs on OpenBSD Mar 8, 2017
@bradfitz bradfitz added this to the Go1.9 milestone Mar 8, 2017
Copy link

@bradfitz bradfitz commented Mar 8, 2017

/cc @mdempsky

Copy link

@mdempsky 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.)

Copy link

@ianlancetaylor ianlancetaylor commented Mar 8, 2017

CC @minux

Copy link

@darinkes 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

Copy link

@ajacoutot ajacoutot commented Mar 10, 2017

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
Copy link

@bradfitz 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.

Copy link

@gopherbot gopherbot commented Jun 17, 2017

CL mentions this issue.

@gopherbot gopherbot closed this in c60d6c0 Jun 17, 2017
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-by: Brad Fitzpatrick <>
Run-TryBot: Brad Fitzpatrick <>
TryBot-Result: Gobot Gobot <>
havoc-io 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:


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.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.