x/build/cmd/gomote: 'gomote ssh' on plan9 can't see files installed by 'gomote put'

[bcmills]

What did you do?

~$ gomote create plan9-386
user-bcmills-plan9-386-0

~$ gomote put14 user-bcmills-plan9-386-0

~$ gomote push user-bcmills-plan9-386-0
# […]

~/go/src$ gomote run user-bcmills-plan9-386-0 /bin/pwd
/tmp/workdir

~/go/src$ gomote run user-bcmills-plan9-386-0 /bin/ls /tmp/workdir
/tmp/workdir/go
/tmp/workdir/go1.4

~$ gomote ssh user-bcmills-plan9-386-0
$ ssh -p 2222 user-bcmills-plan9-386-0@farmer.golang.org # auth using https://github.com/bcmills.keys
# […]
# `gomote push` and the builders use:
# - workdir: /tmp/workdir
# - GOROOT: /tmp/workdir/go
# - GOPATH: /tmp/workdir/gopath
# - env: GO_BUILDER_NAME=plan9-386 GO_TEST_TIMEOUT_SCALE=2
# Happy debugging.
# […]

cpu% ls /tmp/workdir
ls /tmp/workdir
ls: /tmp/workdir: '/tmp/workdir' file does not exist
cpu%

What did you expect to see?

The files reported by gomote run […] /bin/ls /tmp/workdir are also visible when running ls /tmp/workdir under gomote ssh.

What did you see instead?

The files placed by gomote put14 and gomote push are not visible to the gomote ssh process.

@bradfitz tells me that the the ssh and buildlet processes don't share that part of the filesystem namespace.

@0intro, any ideas?

[bradfitz]

I think the /tmp mount is private per process unless explicitly shared to children.

And gomote ssh connects to a sibling process of the buildlet.

Perhaps on Plan 9 the $WORKDIR should be not in /tmp. But we wanted the in-memory filesystem.

@0intro, how do we get the in-memory speed with a OS-wide visible filesystem mount?

[0intro]

We could use ramfs to have an in-memory filesystem mount, however I'm not sure this is the issue.

By default, /tmp is private to the user logged with. The $home/tmp directory is bound to /tmp.
I suspect that the user used to upload the files with gomote push might be different than the user you're logged with using gomote ssh.

Could you run echo $user in the console when running gomote ssh and ensure that the user you're logged with is "glenda"?

Another possibility would be that the $home/tmp directory hasn't been bound to /tmp. You could run ls $home/tmp to ensure the files are there and run bind -ac $home/tmp /tmp to bind the directory.

[bcmills]

Could you run echo $user in the console when running gomote ssh and ensure that the user you're logged with is "glenda"?

~$ gomote ssh user-bcmills-plan9-386-0
$ ssh -p 2222 user-bcmills-plan9-386-0@farmer.golang.org # auth using https://github.com/bcmills.keys
[…]
cpu% echo $user
echo $user
glenda

[bcmills]

You could run ls $home/tmp to ensure the files are there

They're not:

cpu% ls $home/tmp
ls $home/tmp
/usr/glenda/tmp/_fossilconf.old
/usr/glenda/tmp/ts.gnot.1
/usr/glenda/tmp/ts.helix.2.pool.ntp.org
/usr/glenda/tmp/xxx

~/go/src$ gomote run user-bcmills-plan9-386-0 /bin/ls /usr/glenda/tmp
/usr/glenda/tmp/_fossilconf.old
/usr/glenda/tmp/ts.gnot.1
/usr/glenda/tmp/ts.helix.2.pool.ntp.org
/usr/glenda/tmp/xxx

[0intro]

The issue is that ramfs has been started from the rc session that ran the buildlet,
but hasn't been set up to post its channel to /srv to allow other clients to access its files.

The easiest way would be to change /cfg/helix/cpustart to pass the "-s" parameter to ramfs,
so multiple clients could access its files by mounting /srv/ramfs.

Then, you could run mount -c /srv/ramfs /tmp to mount the files served by the ramfs server.

I'll submit a change to make.bash which does this.

[gopherbot]

Change https://golang.org/cl/146038 mentions this issue: env: add -s flag to ramfs in Plan 9 image