podman-container-tools/podman · error

failed to allocate ps argv

Error message

failed to allocate ps argv

What it means

C helper behind 'podman top': create_argv() (called from podmanTopInner in libpod/container_top_linux.go:133) mallocs (len+1) char* slots for the argv of the ps command and exits 255 (special_exit_code, kept in sync with the Go side) when malloc returns NULL. len is the number of ps arguments: the ps binary path plus every ps option/descriptor passed to 'podman top'. A NULL return means the reexec'ed podman process could not allocate memory — real OOM, a tiny RLIMIT_AS, or an absurd argument count.

Source

Thrown at libpod/container_top_linux.c:26

#include <stdio.h>
#include <stdlib.h>
#include <sys/mount.h>
#include <sys/wait.h>
#include <unistd.h>

/* keep special_exit_code in sync with container_top_linux.go */
int special_exit_code = 255;
int join_userns = 0;
char **argv = NULL;

void
create_argv (int len)
{
  /* allocate one extra element because we need a final NULL in c */
  argv = malloc (sizeof (char *) * (len + 1));
  if (argv == NULL)
    {
      fprintf (stderr, "failed to allocate ps argv");
      exit (special_exit_code);
    }
  /* add final NULL */
  argv[len] = NULL;
}

void
set_argv (int pos, char *arg)
{
  argv[pos] = arg;
}

void
set_userns ()
{
  join_userns = 1;
}

View on GitHub (pinned to a2409076ef)

Solutions

1. Retry 'podman top' without extra ps options (fewer arguments, smaller allocation)
2. Raise the memory limit on the podman process's cgroup (systemd MemoryMax/arena) or ulimit -v
3. Free memory / check for OOM killer activity (dmesg | tail) and retry when pressure passes
4. If persistent, report upstream with 'podman info' — allocation size is only pointer-sized per ps arg, so failure indicates environment-level memory starvation

# Sanity-check process limits and arg count before sampling with podman top
#!/bin/sh
# 1. keep ps descriptor lists modest (each becomes an argv slot)
[ $# -le 32 ] || { echo 'too many top descriptors' >&2; exit 1; }
# 2. make sure the calling context is not memory-starved
ulimit -v 2>/dev/null | grep -qv unlimited || true
v=$(ulimit -v 2>/dev/null || echo unlimited)
[ "$v" = unlimited ] || [ "$v" -gt 65536 ] || { echo "ulimit -v too low: $v" >&2; exit 1; }
exec podman top "$@"

When it happens

Trigger: 'podman top CTOR [ps options...]' on a host where the reexec'ed helper is under a cgroup memory limit or ulimit -v that the small malloc exceeds; passing an enormous number/column list of ps descriptors; fork/exec under severe memory pressure. The error appears on stderr of 'podman top' and the command exits 255.

Common situations: cgroups v2 memory.max set very low (systemd slices like MemoryMax=10M); heavy swap exhaustion; scripts looping 'podman top' with long -o column lists; ulimit -v inherited from a restricted service unit.

Related errors

• fork: %m
• mount proc: %m
• open /proc/1/ns/user: %m
• setns NEWUSER: %m
• execve: %m

AI-assisted analysis of podman-container-tools/podman@a2409076ef (2026-08-15). Data as JSON: /api/errors/b4f53252b6cdd708. Report an issue: GitHub.