Attempt to fix flaky port forward test using "netstat" in the container
to check the a process is listening on the port before attempting to
connect.
Also, re-enable the test in a seperate job, but w/ a soft fail. This
will be removed later in favor of adding port-forward to integration
tests to remove the high overhead of starting a new job (scheduling,
compiling runsc, downloading images, etc).
PiperOrigin-RevId: 526135859
Port forward stream mode will be used for k8s. Stream mode takes a
UNIX socket and donates a connected FD to the sandbox in question,
and returns. No proxy process is kept around to do the transfer
and the UDS will be returned to containerd as the address on which
to send i/o to the forwarded port.
PiperOrigin-RevId: 521823250
Add portforward comand so that we can use runsc to forward connections
to container ports. This will eventually be supported in k8s.
PiperOrigin-RevId: 520739913
Serves as a regression test for #8126.
Our unit tests didn't catch the issue because they run runsc with the flag
-TESTONLY-unsafe-nonroot. Docker tests are more e2e, they run tests in Docker
containers.
Fixes#8126
PiperOrigin-RevId: 488945922
k8s.gcr.io/busybox:latest doesn't have the arm variant, so
let's use the upstream busybox and create /etc/recolv.conf symlink.
PiperOrigin-RevId: 450059917
Linux behaves differently for regular files and dirs for poll(2)/select(2)
compared to epoll_ctl(2). The latter returns EPERM for file and dirs.
I've also changed host FDs to behave like the underlying FD in regards
to epoll to keep it compatible with docker.
Fixes#7134
PiperOrigin-RevId: 429412692
Docker maps stdin to `/dev/null` which doesn't support epoll. Host FD
was ignoring the error and suceeding the epoll_ctl call from the
container, giving false impressing that epoll would be notified.
This required plumbing failure to all waiter.Waitable.EventRegister
callers and implementers.
Closes#6795
PiperOrigin-RevId: 414797621
Our implementation of vfs.CheckDeleteSticky was not consistent with Linux,
specifically not consistent with fs/linux.h:check_sticky().
One of the biggest differences was that the vfs implementation did not
allow the owner of the sticky directory to delete files inside it that belonged
to other users.
This change makes our implementation consistent with Linux.
Also adds an integration test to check for this. This bug is also present in
VFS1.
Updates #3027
PiperOrigin-RevId: 355557425
This makes it easier to add more tests that run on Ubuntu. We can now just
add a bash script and call that from integration_test without having to set up
another image.
PiperOrigin-RevId: 355000410
#5274 broke `make load-basic_fsstress` target. It works locally but for some
inconceivable reason it fails to build on Kokoro.
Error message:
```
Step 1/12 : FROM alpine
---> 1fca6fe4a1ec
Step 2/12 : RUN apk add git
---> Running in 109a5326259a
standard_init_linux.go:207: exec user process caused "no such file or directory"
The command '/bin/sh -c apk add git' returned a non-zero code: 1
make: *** [load-basic_fsstress] Error 1
tools/images.mk:149: recipe for target 'load-basic_fsstress' failed
```
Copied the approach from the following issue to achieve the same goal:
https://github.com/nodejs/docker-node/issues/586#issue-273737852.
PiperOrigin-RevId: 352602945
This change allows Dockerfiles named Dockerfile.$(ARCH) and makes list-images
list only supported architectures.
Updates #2847
PiperOrigin-RevId: 336108293
9P2000.L is silent as to how readdir RPCs interact with directory mutation. The
most performant option is for Treaddir with offset=0 to restart iteration,
avoiding needing to walk+open+clunk a new directory fid between invocations of
getdents64(2), and the VFS2 gofer client assumes this is the case. Make this
actually true for the runsc fsgofer.
Fixes#3344, #3345, #3355
PiperOrigin-RevId: 324090384
This change moves all Docker images to a standard location, and abstracts the
build process so that they can be maintained in an automated fashion. This also
allows the images to be architecture-independent.
All images will now be referred to by the test framework via the canonical
`gvisor.dev/images/<name>`, where `<name>` is a function of the path within the
source tree.
In a subsequent change, continuous integration will be added so that the images
will always be correct and available locally.
In the end, using `bazel` for Docker containers is simply not possible. Given
that we already have the need to use `make` with the base container (for
Docker), we extend this approach to get more flexibility.
This change also adds a self-documenting and powerful Makefile that is intended
to replace the collection of scripts in scripts. Canonical (self-documenting)
targets can be added here for targets that understand which images need to be
loaded and/or built.
PiperOrigin-RevId: 308322438
