What causes "getting process name: %w" in kubernetes/kops?

Mount /proc (or ensure procfs is available) in the container/sandbox running kops

getting process name: %w

Error message

getting process name: %w

What it means

kOps' OpenTelemetry setup derives the trace-exporter filename from the running executable's path. When os.Executable() fails (e.g. the binary path cannot be resolved), newTraceProvider wraps the failure as "getting process name" and aborts SDK initialization.

Source

Thrown at cmd/kops/otel.go:123

	}
	if dest == "" {
		dest = os.Getenv("OTEL_EXPORTER_OTLP_DIR")
		if dest != "" {
			destIsDirectory = true
		}
	}
	if dest == "" {
		return nil, nil
	}

	// If we are writing to a directory, construct a (likely) unique name
	if destIsDirectory {
		if err := os.MkdirAll(dest, 0755); err != nil {
			return nil, fmt.Errorf("creating directories %q: %w", dest, err)
		}
		processName, err := os.Executable()
		if err != nil {
			return nil, fmt.Errorf("getting process name: %w", err)
		}
		processName = filepath.Base(processName)
		processName = strings.TrimSuffix(processName, ".exe")
		pid := os.Getpid()
		timestamp := time.Now().UTC().Format(time.RFC3339)
		filename := fmt.Sprintf("%s-%d-%s.otel", processName, pid, timestamp)
		dest = filepath.Join(dest, filename)
	}

	traceExporter, err := otlptracefile.New(ctx, otlptracefile.WithPath(dest))
	if err != nil {
		return nil, err
	}

	traceProvider := trace.NewTracerProvider(
		trace.WithBatcher(traceExporter,
			// Default is 5s. Set to 1s for demonstrative purposes.
			trace.WithBatchTimeout(time.Second)),

View on GitHub (pinned to 4c8573c808)

Solutions

Mount /proc (or ensure procfs is available) in the container/sandbox running kops
Re-download or restore the kops binary if it was deleted or moved while in use
Run the binary from a real filesystem path rather than via /proc/<pid>/fd or a deleted inode
If the failure persists, pass a disable/OTel-off flag so newTraceProvider is not invoked

Example fix

// before (container without procfs)
// docker run --restart ... kops ...
// after
// docker run --restart ... -v /proc:/proc:rw kops ...  (or use an image with proc mounted)

Defensive patterns

Strategy: fallback

Validate before calling

if _, err := os.Executable(); err != nil {
	log.Fatalf("cannot resolve executable path (is /proc mounted?): %v", err)
}

Try / catch

provider, err := newTraceProvider(ctx)
if err != nil {
	log.Printf("otel disabled, continuing without tracing: %v", err)
	return nil
}

Prevention

Run kops in containers with /proc mounted
Never delete or replace the binary while it is executing; use atomic rename to a new inode and restart
Verify the binary runs from a real filesystem path, not a deleted fd

When it happens

Trigger: Running the kops binary in an environment where the kernel cannot supply /proc/self/exe or equivalent: the binary was deleted/replaced while running, or running in a minimal container/chroot where procfs is not mounted.

Common situations: Running kops inside scratch/DISTROLESS containers without /proc mounted; invoking the binary via a deleted file descriptor; exotic sandbox environments (some CI runners, nsjail) where os.Executable() returns ENOENT.

Related errors

AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/2706179497118fa3. Report an issue: GitHub.