vole
Clone
Read only, no credentials:
https://rodent.software/vole.git
Write over SSH with a registered key:
git clone ssh://git@rodent.software:2222/vole.git
A free and open-source forge that lives in your Git repo.
Bound the runner's containers and keep its disk free
4e3759da08a603ede50107e89a23ff6d5432b7ac · Keenan Nemetz · 7h ago · parent c4ad0d5a
Bound the runner's containers and keep its disk free The container boundary was good and the resource the job consumes was not. A job could fork without a bound, write /tmp until the machine's RAM was gone, and fill the disk its workspace sits on — and the runner would only notice when a build died. The isolation protects the forge's data; this protects the machine that runs the code. - `--container-pids` now defaults to 2048 and zero means the default, not "no limit": a bound nobody set is the easiest one to be missing, and a job that can fork without one is a fork bomb away from taking the machine. - `--container-tmpfs` is new and defaults to 1G. /tmp is a tmpfs, so its size is memory, and an unsized one is a build that fills RAM without writing a byte to the workspace. It is passed to service containers too. - `--container-memory` stays the operator's setting rather than a default, because the right number is the machine's size and a wrong default would show up as an OOM kill in someone's build. All three places a runner is configured now set it: the packaged runner.env example, the manual steps in the deploy guide, and the cloud-init template (RUNNER_MEMORY, default 4G, alongside RUNNER_PIDS, RUNNER_TMPFS and RUNNER_DISK_RESERVE). - `--disk-reserve` (default 2G) is how the job tree is bounded. It is a host bind mount, so the runtime cannot quota it and a filesystem quota needs root; a walker over the tree would cost more than it protects. What the runner can promise is that it notices: one statfs per second while a command runs, and the job is stopped below the reserve with the numbers in its log. `--dir` on its own sized filesystem is the hard bound, and the docs say so. - The runner unit gets `MemoryMax=90%` as the backstop under all of it, for a job that gets past its own cgroup. It is a percentage so the unit does not have to know the machine. TasksMax is deliberately not set: the container's own --container-pids already applies, and a unit value would have to track --jobs and --container-pids and would fail builds, looking like the workflow's fault, when they drifted apart. A workflow still cannot raise or remove any of this: the limits are flags on the runner and the unit, never fields a job can set. scripts/check-deploy.py now fails when the rendered runner arguments stop carrying the memory, pids, tmpfs or disk limits, so the first-boot file cannot quietly lose them. Closes 01M6S798BH0BK00R2B5N1KDJYM
ci/agent/sandbox_test.go +18
| @@ -240,3 +240,21 @@ exit 125 | |||
| 240 | 240 | t.Fatalf("Run = %v, want %q", err, want) | |
| 241 | 241 | } | |
| 242 | 242 | } | |
| 243 | |||
| 244 | // The size of the job's /tmp is the operator's, and it reaches the container settings | ||
| 245 | // the runner actually uses. | ||
| 246 | func TestContainerOptionsCarryTheTmpfsLimit(t *testing.T) { | ||
| 247 | dir := t.TempDir() | ||
| 248 | if err := os.WriteFile(filepath.Join(dir, "docker"), []byte("#!/bin/sh\nexit 0\n"), 0o755); err != nil { | ||
| 249 | t.Fatal(err) | ||
| 250 | } | ||
| 251 | t.Setenv("PATH", dir+string(os.PathListSeparator)+os.Getenv("PATH")) | ||
| 252 | |||
| 253 | box, err := containerOptions(Options{ContainerRuntime: "docker", ContainerTmpfs: "3g"}, t.TempDir()) | ||
| 254 | if err != nil { | ||
| 255 | t.Fatal(err) | ||
| 256 | } | ||
| 257 | if box.Tmpfs != "3g" { | ||
| 258 | t.Fatalf("tmpfs = %q, want 3g", box.Tmpfs) | ||
| 259 | } | ||
| 260 | } | ||