Using Podman on Linux workstations, especially Fedora 35 #12693
Replies: 7 comments 3 replies
-
Half year later: Podman 4 doesn't work on Fedora 36 Workstation with Gnome 4.2 doesn't work at all: podman start of existing container fails when container was created by rootless user and the same user attempts to start it. Very strange set of options is passed to conmon and then crun does very strange manipulation with /proc/self/oom_adj that fails. See log below: ================================ DEBU[0000] Received: -1 open executable: Permission denied: OCI permission denied Why conmon is started with syslog option? In the workstation environment it contradicts the log separation requirement and dangerous from the security point of view to use syslog by the nonprivileged rootless user. Session-level journald socket looks more safe. |
Beta Was this translation helpful? Give feedback.
-
@vrothberg Maybe, BPF related? Indeed, it was missed in my setup. [pavelsosin@Dell ~]$ podman info
==================
|
Beta Was this translation helpful? Give feedback.
-
I suppose that the root cause is located in the OS.exec which Conmon uses to run crun. This is omething strange with OS.exec in thr golang libraries for all platforms because Google search returns dozens of reported issues regarding os.fork and os.exec that return "Permition denied" or "can't access". It simply doesn't work. Maybe, because it needs shell to run and any shell I tried to fork from the gnome-terminal can't execute any executable, bash is fails for example. I would be happy to provide output of bash capsh --print but it fails with the same error - '/usr/bin/capsh couldn't execute binary file". when executed by either root or rootless user. |
Beta Was this translation helpful? Give feedback.
-
@vrothberg Only for curiosity: running Fedora image inside Podman machine on Fedora ends with the same error: |
Beta Was this translation helpful? Give feedback.
-
Inside Podman machine from Fedora image it works when cgroups is set to disabled. But there podman runs inside plane remote session as core user. I think that the conclusion is that in the Workstation environment either podman or conmon creates container's cgroup incorrectly in the session hierarchy and the container is stillborn. Indeed, this is discussable what is container/conmon cgroup in the Gnome session. Could somebody pay attention? |
Beta Was this translation helpful? Give feedback.
-
@mheon I would like to try running podman service inside Fedora CoreOS VM under Fedora WS Boxes. Unfortunately, CoreOS ISO image is published without dnf. So, I need url of the good Podman release candidate rpm. From this point everything should be very similar to any other Workstation running podman via podman machine create command or podman-in-docker container. |
Beta Was this translation helpful? Give feedback.
-
Yes!!!! After the recent Fedora 36 full upgrade I got podman 4.1 inside Fedora CoreOS Gnome Box including podman system service. In other words Podman service can run virtualized on the Fedora 36 Workstation at least at POC level. |
Beta Was this translation helpful? Give feedback.
-
Currently, Podman is delivered with Fedora 35 Workstation but doesn't work correctly. Unlike Server and "Regular" distros without Desktop Podman has very few dependencies - it needs only systemd manager for control groups handling and HOME, XDG_DATA_HOME and XDG_RUNTIME_DIR mounted at the System boot and user's login. When Podman is run on Linux workstation inside Desktop session it becomes very dependent from many system or user services like systemd-homed, dbus-broker, journald, that provide necessary services to the Podman itself, Podman service and Podman containers running as Systemd units. Analyzing Systemd units tree I found that other applications don't hesitate to check, wait and trigger starting of all used services: those that use storage waits mount and home.mount, those that use journal wait for journald, those that manages control groups wait for session service, those that need networking wait for network.target. those that communicate with other services wait for dbus-broker, etc.
It looks like that they use transient systemd unit as a dependencies helper. etc. Podman doesn't do it and it causes synchronization with systemd-homed problems. If any of dependency fails to start the Podman behavior turns to be unpredictable.
Beta Was this translation helpful? Give feedback.
All reactions