Closed luckylinux closed 8 months ago
Seems to be due to some SSL (mis / lack of) configuration. Seems to work now - See comments in https://github.com/eclipse/mosquitto/issues/2961
so can we close this issue or is there anything to fix/check in Podman?
From your point of view podman is maybe normal.
But to think that a permission error like this (which points to a systemd setting and crun/runc bugs as well) is actually due to some SSL configuration within a container.
That's totally counter intuitive in my view. The error is severely misleading.
I don't think the SSL configuration can affect the oom_score_adj
value and the error you've reported here.
Maybe that caused a systemctl daemon-reload
or something like that?
It was the ssl cert as indicated in the mosquitto log. That's why the podman error made no sense whatsoever. As soon as I regenerated proper certificates everything started working and the error disappeared
This is just a harmless log line from conmon, it is only logged at debug level. Basically conmon tries to make itself unkillable but this is not allowed because it cannot lower the oom score as rootless user. This is totally expected and not a problem. I guess we could try to make conmon aware of it and not log this line as rootless.
Just run without --log-level=debug then you will not see this message.
Yeah without --log-devel=debug I didn't see anything when I started the container. But then I could see it was immediately down. Hence the need for --log-level=debug in the first place.
From the other threads I thought that this failed to write to /proc/self/oom_score_adj: Permission denied was fatal, as they couldn't run the container otherwise. Re-reading the thread some people talk about "error" some say that the converter runs after it.
From your log the container is started, if it exited after that then it is because the process inside exited not because it failed to start so I suggest you look at your application logs.
There were fatal oom_score_adj error but they were because of the oci runtime hard failing as we requested an invalid value. conmon never hard failed because of this.
Anyway since you have it working now I am going to close this one.
Issue Description
Podman rootless.
When starting some containers I get
For instance eclipse-mosquitto container image gives this error, while homeassistant container image works correctly (didn't do anything yet, but it boots and web interface can be accessed normally).
See for the Description on Debian Bookworm (Stable) with Podman 4.3.1 (https://github.com/containers/podman/issues/3024#issuecomment-1834480475).
What I tried:
On Debian Trixie I also tried to rebuild the eclipse-mosquitto container image using the provided Dockerfile and docker-entrypoint.sh file, as well as the required basic configuration from https://github.com/eclipse/mosquitto/tree/15292b20b0894ec7c5c3d47e4b22ee9d89f91132/docker/2.0
I tried, following the advices on https://github.com/containers/podman/issues/3024, to set "OOMScoreAdjust=" (nothing) in both
/etc/systemd/system/user@.service
and/etc/systemd/system/user@.service.d/override.conf
but it doesn't help.Not sure if these files are not used by Debian or what the issue really is.
root@Rock5B-01:~# cat /etc/systemd/system/user@.service
root@Rock5B-01:~# cat /etc/systemd/system/user@.service.d/override.conf
Steps to reproduce the issue
Steps to reproduce the issue
I put here the script that I roughly used to do the setup. Some later manual fixes might have been required. E.g. subuid / subgid generation and unique entries in /etc/subgid and /etc/subuid ranges and starting values need to be manually adjusted. In case of errors, multiple entries might be placed in /etc/fstab.
Called like:
./setup_podman_rock5b_debian_zfs.sh "podman" "zdata/PODMAN" "zfs"
./setup_podman_rock5b_debian_zfs.sh "podman-test" "zdata/PODMAN-TEST" "zvol"
Describe the results you received
When starting some containers such as eclipse-mosquitto I get
Journalctl log on Debian Trixie as root
Journalctl on Debian Trixie as podman-test user
Output of podman start with debug informatio for the affected container
Describe the results you expected
Podman starting the container correctly.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
No
Additional environment details
uname -a
Linux Rock5B-01 6.6.3-1-arm64 #1 SMP PREEMPT Debian 6.6.3-1 (2023-11-28) aarch64 GNU/LinuxDebian GNU/Linux AARCH64 / ARM64 Trixie (previously was Bookworm)
podman version
Client: Podman Engine Version: 4.7.2 API Version: 4.7.2 Go Version: go1.21.3 Built: Thu Jan 1 00:00:00 1970 OS/Arch: linux/arm64dpkg -s podman
Package: podman Status: install ok installed Priority: optional Section: admin Installed-Size: 39476 Maintainer: Debian Go Packaging Team pkg-go-maintainers@lists.alioth.debian.org Architecture: arm64 Source: libpod Version: 4.7.2+ds1-2 Depends: conmon, crun | runc, golang-github-containers-common, libc6 (>= 2.34), libdevmapper1.02.1 (>= 2:1.02.97), libgpgme11 (>= 1.4.1), libseccomp2 (>= 2.5.0), libsqlite3-0 (>= 3.36.0), libsubid4 (>= 1:4.11.1) Recommends: buildah (>= 1.31), catatonit | tini | dumb-init, dbus-user-session, passt, slirp4netns, uidmap Suggests: containers-storage, docker-compose, iptables Conffiles: /etc/cni/net.d/87-podman-bridge.conflist a87c090f17c5274af878e7106e969b60 /etc/containers/libpod.conf ceec5a77b5f6a56d212eeed7b707d322 Description: tool to manage containers and pods Podman (the POD MANager) is a tool for managing containers and images, volumes mounted into those containers, and pods made from groups of containers. . At a high level, the scope of Podman and libpod is the following:Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting