podman-container-tools/podman · error

fork: %m

Error message

fork: %m

What it means

fork() failed inside fork_exec_ps(), the cgo helper that runs ps in the container's PID namespace for 'podman top'. %m expands to strerror(errno): typically EAGAIN (RLIMIT_NPROC, cgroup pids.max, or kernel threads-max exceeded) or ENOMEM. The helper exits 255 (special_exit_code), so the user sees this message and a 255 exit from the podman top reexec.

Source

Thrown at libpod/container_top_linux.c:65

  this is done so we can mount proc after the fork because the pid namespace is
  only active after spawning children.
*/
void
fork_exec_ps ()
{
  int r, status = 0;
  pid_t pid;

  if (argv == NULL)
    {
      fprintf (stderr, "argv not initialized");
      exit (special_exit_code);
    }

  pid = fork ();
  if (pid < 0)
    {
      fprintf (stderr, "fork: %m");
      exit (special_exit_code);
    }
  if (pid == 0)
    {
      r = mount ("proc", "/proc", "proc", 0, NULL);
      if (r < 0)
        {
          fprintf (stderr, "mount proc: %m");
          exit (special_exit_code);
        }
      if (join_userns)
        {
          // join the userns to make sure uid mapping match
          // we are already part of the pidns so so pid 1 is the main container process
          r = open ("/proc/1/ns/user", O_CLOEXEC | O_RDONLY);
          if (r < 0)
            {
              fprintf (stderr, "open /proc/1/ns/user: %m");

View on GitHub (pinned to a2409076ef)

Solutions

1. Raise the pids limit: run the container with a larger --pids-limit (or remove it)
2. Check and raise ulimit -u (RLIMIT_NPROC) for the user running podman, and systemd TasksMax for rootless sessions
3. Clean up leaked processes/zombies in the container or session, then retry podman top
4. Verify with: cat /sys/fs/cgroup/pids.max and ps -eLf | wc -l

Example fix

# before
podman run --pids-limit 10 -d quay.io/libpod/alpine top -d

# after
podman run --pids-limit 200 -d quay.io/libpod/alpine top -d

# Pre-flight: is there headroom to fork one more process?
#!/bin/sh
pidmax=$(cat /sys/fs/cgroup/pids.max 2>/dev/null || cat /sys/fs/cgroup/pids/pids.max 2>/dev/null || echo max)
[ "$pidmax" = max ] || {
  cur=$(cat /sys/fs/cgroup/pids.current 2>/dev/null || cat /sys/fs/cgroup/pids/pids.current)
  [ "$cur" -lt $((pidmax - 5)) ] || { echo "pids cgroup nearly full: $cur/$pidmax" >&2; exit 1; }
}
nproc_lim=$(ulimit -u)
[ "$nproc_lim" = unlimited ] || [ "$(ps -o nlwp= -p $$ 2>/dev/null || echo 0)" -lt "$nproc_lim" ] || true
exec podman top "$@"

#!/bin/sh
# EAGAIN (Resource temporarily unavailable) from fork is retryable
i=0
while ! out=$(podman top "$ctr" 2>&1); do
  case "$out" in *fork:*Resource*temporarily*unavailable*|*'fork: EAGAIN'*)
      i=$((i+1)); [ $i -le 3 ] || { echo "$out" >&2; exit 1; }
      sleep 2;;
    *) echo "$out" >&2; exit 1;;
  esac
done
printf '%s\n' "$out"

When it happens

Trigger: 'podman top CTOR' when the podman process cannot create one more process: container's pids cgroup at its --pids-limit, user's ulimit -u exhausted (rootless), or system-wide threads-max reached. EAGAIN is the common errno.

Common situations: Containers run with a very low --pids-limit whose podman top helper shares the limit context; fork-bomb protection (kernel.threads-max, systemd TasksMax) tripping; zombie/process leakage from a leaking workload.

Related errors

• fork: %m
• cannot fork: %m
• failed to allocate ps argv
• mount proc: %m
• open /proc/1/ns/user: %m

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