fix: give the pod a resolvable hostname (own-hostname resolution)#82
Merged
Conversation
…s own hostname 0.4.0 moved name resolution into a script-owned /etc/hosts under --no-hosts to kill the pre-6.0.0 stop-wipe bug. But --no-hosts also stops Podman from adding each container's own hostname line, so the hostname is the random container ID, absent from the owned file: hostname -f then fails with 'Temporary failure in name resolution' and an image whose startup resolves its own hostname (e.g. a KeyDB-sentinel image) crash-loops and never goes healthy -- a regression from 0.1.8, which used no --no-hosts and let Podman add the line. Give the pod a private UTS namespace and the pod name as hostname (podman pod create --uts private --hostname <pod>; --uts private is required, Podman refuses --hostname in the host UTS namespace), and add 127.0.0.1 <pod> to the owned /etc/hosts. A pod shares one UTS namespace, so the hostname is pod-wide; per-service hostname: keys are unchanged. Verified end-to-end on Podman 5.8.1 and 6.0.1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
0.4.0 moved pod-internal name resolution into a script-owned
/etc/hostsunder--no-hosts(to kill the pre-6.0.0 stop-wipe bug). But--no-hostsalso stops Podman from adding each container's own hostname line. The container's hostname is then the random container ID, absent from the owned file, so:Images whose startup resolves their own hostname — e.g. a KeyDB-sentinel image whose supervisor does — crash-loop and never go healthy, so
wait_healthytimes out. This is a regression from 0.1.8, which used no--no-hostsand let Podman add the own-hostname line (it worked there even with a random container-ID hostname).Fix
podman pod creategains--uts private --hostname <pod-name>.--uts privateis required — in the host UTS namespace Podman refuses--hostname(cannot set hostname ... host UTS namespace). A pod shares one UTS namespace, so per-container hostnames are impossible on 5.x/6.x (verified); the pod name is the single shared hostname.127.0.0.1 <pod-name>to the owned/etc/hostsso that hostname resolves.Per-service
hostname:keys are unchanged: resolvable by peers via the hosts file, not set as a container's own name (0.1.8 didn't honor them as real hostnames either, and the value is irrelevant to resolution).Verification
quay.io/podman/stable:v5.8.1) and local 6.0.1: a service whose healthcheck ishostname -fgoes healthy, and a peer resolves its own hostname (OWN-HOSTNAME-OK).--health-cmdcompose2pod emits for["CMD", ...]is accepted by Podman 5.8.1 (the healthcheck rendering was not the bug).test_pod_gets_private_uts_and_hostnamefirst, then fix.just test-ci— 1403 passed, 100% coverage.just lint-ci— clean.Rationale:
planning/changes/2026-07-22.02-pod-hostname-own-resolution.md. Architecture promoted inarchitecture/supported-subset.md(owned-/etc/hostsbullet).