Debugging cron job execution failures in rootless podman containers due to missing systemd user session environment variables

Why I Worked on This

I run rootless Podman on WSL2 because I prefer not running containers as root. My setup includes docker-compose pointing at Podman’s socket through systemd user services, which lets me use compose files without Docker Desktop.

After a WSL update to 2.5.x, everything broke. Podman commands threw warnings about missing systemd user sessions, systemctl --user commands failed with “No such file or directory,” and my compose workflows stopped working entirely.

This wasn’t a configuration issue on my side—I had already enabled lingering, set up the socket service, and confirmed it all worked on WSL 2.4.13. The problem appeared immediately after the update.

What Actually Broke

The core issue was that WSL 2.5.x changed how systemd user sessions are initialized. When I logged into my distro, the XDG_RUNTIME_DIR environment variable wasn’t being set, which meant:

• The systemd user instance couldn’t start properly
• The D-Bus session bus at /run/user/1000/bus was missing
• Podman fell back to cgroupfs mode instead of using systemd for cgroup management
• systemctl --user commands failed because they couldn’t connect to the user session

Running podman ps produced warnings like:

WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available
WARN[0000] Falling back to --cgroup-manager=cgroupfs
WARN[0000] Failed to add pause process to systemd sandbox cgroup: dial unix /run/user/1000/bus: connect: no such file or directory

These weren’t just noise—they indicated that Podman couldn’t use systemd for process management, which breaks rootless container isolation and resource limits.

What I Tried First

I assumed it was a lingering or session issue, so I re-ran:

loginctl enable-linger $USER

That didn’t help. I checked if the systemd user instance was running:

systemctl --user status

It returned “Failed to connect to bus: No such file or directory.” The user instance wasn’t starting at all.

I verified that /etc/wsl.conf had systemd=true under [boot], did a wsl --shutdown, and restarted. Still broken.

What Actually Fixed It

The issue was that WSL 2.5.x no longer automatically sources /etc/profile or sets up XDG_RUNTIME_DIR during the initial login shell. This broke the chain that normally triggers systemd user session initialization.

I had to manually ensure the environment was set up before running any Podman or systemctl commands. I added this to my ~/.bashrc:

if [ -z "$XDG_RUNTIME_DIR" ]; then
  export XDG_RUNTIME_DIR=/run/user/$(id -u)
  if [ ! -d "$XDG_RUNTIME_DIR" ]; then
    sudo mkdir -p "$XDG_RUNTIME_DIR"
    sudo chown $(id -u):$(id -g) "$XDG_RUNTIME_DIR"
    sudo chmod 700 "$XDG_RUNTIME_DIR"
  fi
fi

After sourcing the updated bashrc or opening a new shell, systemctl --user status worked, and Podman stopped complaining.

For cron jobs, which don’t inherit user shell environments, I had to explicitly set the variable in the crontab or use a wrapper script:

#!/bin/bash
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
podman ps

This ensured the systemd user session environment was available even in non-interactive contexts.

Why This Happened

WSL’s systemd integration relies on PAM (Pluggable Authentication Modules) to set up user sessions. In 2.4.x, this happened automatically during login. In 2.5.x, something changed in how WSL initializes the login shell, and the PAM session wasn’t being created properly.

This isn’t a Podman bug—it’s a gap in how WSL 2.5.x handles systemd user sessions. The same issue would affect any tool expecting a systemd user instance (like user-level timer units or socket-activated services).

What Still Doesn’t Work Perfectly

Even with XDG_RUNTIME_DIR set, there are edge cases:

• If the distro is stopped and restarted, the runtime directory might not persist, requiring manual recreation
• Cron jobs still need explicit environment setup—there’s no way to make them inherit the user session automatically
• Some systemd features (like systemd-run --user) behave inconsistently depending on how the shell was started

I also noticed that rolling back to WSL 2.4.13 made everything work again without any changes, which confirms this is a regression in 2.5.x.

Key Takeaways

• Rootless Podman on WSL relies on systemd user sessions, which need XDG_RUNTIME_DIR to function
• WSL 2.5.x broke the automatic setup of this variable during login
• You can work around it by manually setting the variable in your shell config and cron job wrappers
• This isn’t just a Podman issue—it affects anything using systemd user services
• If you don’t need the latest WSL features, staying on 2.4.13 avoids the problem entirely

I reported this to the WSL team with full logs. Until it’s fixed upstream, the environment variable workaround is the only reliable way to keep rootless Podman working on WSL 2.5.x.