Package: podman
Version: 3.0.1+dfsg1-3+deb11u1
Severity: normal
Tags: upstream
Dear Maintainer,
I have noticed that operations, such as 'podman ps' occationally print
warning messages. Here is an example of this:
paul@celebrimbor:~/git/podman (main)$ podman ps
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user
session available
WARN[0000] For using systemd, you may need to login using an user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl
enable-linger 1000` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user
session available
WARN[0000] For using systemd, you may need to login using an user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl
enable-linger 1000` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
paul@celebrimbor:~/git/podman (main)$
I tracked this problem down to the value of DBUS_SESSION_BUS_ADDRESS and
how podman parses the value of this environment variable. It appears
that this environment variable is (in general) a comma-separated list of
key-value pairs, although I couldn't find a definitive statement on this
in the DBUS specs.
The podman code in the v3.0 branch (from which bullseye's v3.0.1 is
tagged) assumes that the environment variable is a single key-value
pair; i.e., that it contains no commas. This works fine sometimes;
e.g.,
paul@celebrimbor:~$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus
paul@celebrimbor:~$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
paul@celebrimbor:~$
However, sometimes the DBUS_SESSION_BUS_ADDRESS value contains a 'guid'
item; e.g.,
paul@celebrimbor:~/git/podman (main)$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus,guid=5c5c86e60aa45c4c51dcfa0a630db85e
paul@celebrimbor:~/git/podman (main)$
I haven't determined under what circumstances trigger the
DBUS_SESSION_BUS_ADDRESS environment variable to contain this additional
'guid' item. Sometimes it's there and sometimes not.
The presence of the 'guid' item causes some operations (e.g., 'podman
ps') to issue the above warning. If the 'guid' item is removed then
'podman ps' works as expected:
paul@celebrimbor:~/git/podman (main)$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus,guid=5c5c86e60aa45c4c51dcfa0a630db85e
paul@celebrimbor:~/git/podman (main)$ DBUS_SESSION_BUS_ADDRESS=$(echo
$DBUS_SESSION_BUS_ADDRESS | cut -d, -f1) podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
paul@celebrimbor:~/git/podman (main)$
This problem appears to be specific to the podman version. In
particular, it appears to have been fixed upstream with commit
732ece6ae2. This commit touches various parts of the code base. Fixing
how the DBUS_SESSION_BUS_ADDRESS value is parsed is only one aspect of
that change.
Commit 732ece6ae2 is available from podman v3.3.0 onwards, but the
change has not be back-ported to the earlier branches. Therefore, the
v3.0 branch (from which v3.0.1 is tagged) contains this assumption about
the DBUS_SESSION_BUS_ADDRESS value.
I opened an issue against podman in github, requesting that the change
be back-ported to the v3.0 branch:
https://github.com/containers/podman/issues/15546
This would allow a new v3.0 release (v3.0.3) that Debian could adopt and
resolve this issue.
The issue was closed, requesting that I open a ticket here (against the
Debian package) and that I cite the above issue as context.
At the risk of pointing out the obvious, I would suggest there are four
ways to resolve this issue:
1. Fix DBUS_SESSION_BUS_ADDRESS so it never includes the 'guid' value.
2. Pursuade upstream to back-port (part of) commit 732ece6ae2 to the
v3.0 branch and make another release (v3.0.3) that Debian could
adopt.
3. Patch the v3.0.1 source code (using part of commit 732ece6ae2)
within the Debian build process.
4. Adopt a newer version of podman in bullseye. I see that bookworm is
currently set to use v3.4.7.
For me, this is a relatively minor problem, as I know how to work around
it; however, it may cause others to waste time searching for a solution.
Moreover, there are several web pages / forum posts that describe these
symptoms but do not make a correct diagnostic about what is the
underlying problem. Therefore, I think there is a risk that people may
make unnecessary configuration changes or configure their system
sub-optimally.
Cheers,
Paul.
-- System Information:
Debian Release: 11.4
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-17-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.0.25+ds1-1.1
ii containernetworking-plugins 0.9.0-1+b6
ii golang-github-containers-common 0.33.4+ds1-1+deb11u1
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc6 2.31-13+deb11u3
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libgpgme11 1.14.0-1+b2
ii libseccomp2 2.5.1-1+deb11u1
ii runc 1.0.0~rc93+ds1-5+deb11u2
Versions of packages podman recommends:
ii buildah 1.19.6+dfsg1-1+b6
ii fuse-overlayfs 1.4.0-1
ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7
ii slirp4netns 1.0.1-2
ii tini 0.19.0-1
ii uidmap 1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage <none>
pn docker-compose <none>
-- Configuration Files:
/etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Permission denied:
'/etc/cni/net.d/87-podman-ptp.conflist'
-- no debconf information
