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

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

Open
bcmills opened this issue Oct 30, 2018 · 6 comments
Labels
Builders x/build issues (builders, bots, dashboards) help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Plan9
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented Oct 30, 2018

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?

@gopherbot gopherbot added this to the Unreleased milestone Oct 30, 2018
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Oct 30, 2018
@bradfitz
Copy link
Contributor

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

0intro commented Oct 30, 2018

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

bcmills commented Oct 30, 2018

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

bcmills commented Oct 30, 2018

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

0intro commented Oct 30, 2018

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

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

gopherbot pushed a commit to golang/build that referenced this issue Oct 31, 2018
We add -s flag to ramfs to post its channel
on /srv/ramfs, so multiple clients could
access its files.

Updates golang/go#28485.

Change-Id: Id39b17fcc3bec2b5fae3a16841ab2414e60361b3
Reviewed-on: https://go-review.googlesource.com/c/146038
Reviewed-by: Bryan C. Mills <bcmills@google.com>
@dmitshur dmitshur removed their assignment Nov 29, 2020
@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Plan9
Projects
None yet
Development

No branches or pull requests

5 participants