Replies: 8 comments 4 replies
-
|
do you have any configuration that overrides the cgroup manager? From the message above I see The cgroupManager should be set to |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Giuseppe. I haven't chosen
Issue #5443 mentions systemd linger. I do have that enabled for I'm also logging in over SSH, not by switching user with
Edit: Edit: If I create and start the container while passing |
Beta Was this translation helpful? Give feedback.
-
|
do you have |
Beta Was this translation helpful? Give feedback.
-
|
I didn't have one, no. Does this file replace I downloaded I removed and recreated all of my containers. |
Beta Was this translation helpful? Give feedback.
-
|
what is the systemd version you are using? |
Beta Was this translation helpful? Give feedback.
-
|
I think that release was around February or March last year. I tried upgrading to systemd 250 (from Debian
I now have two separate issues:
|
Beta Was this translation helpful? Give feedback.
-
|
vfs is very slow. Probably your kernel doesn't support native overlay, in this case I suggest to install fuse-overlayfs. Not sure if crun would help here, but we can give it a try. If you run the container with crun ( |
Beta Was this translation helpful? Give feedback.
-
The issuue persists, and host:
arch: amd64
buildahVersion: 1.24.1
cgroupControllers:
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: 'conmon: /usr/bin/conmon'
path: /usr/bin/conmon
version: 'conmon version 2.0.25, commit: unknown'
cpus: 1
distribution:
codename: bullseye
distribution: debian
version: "11"
eventLogger: file
hostname: <removed>
idMappings:
gidmap:
- container_id: 0
host_id: 33
size: 1
- container_id: 1
host_id: 951968
size: 65536
uidmap:
- container_id: 0
host_id: 33
size: 1
- container_id: 1
host_id: 951968
size: 65536
kernel: 5.10.0-11-amd64
linkmode: dynamic
logDriver: k8s-file
memFree: 111452160
memTotal: 1023930368
networkBackend: cni
ociRuntime:
name: crun
package: 'crun: /usr/bin/crun'
path: /usr/bin/crun
version: |-
crun version 0.17
commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
path: /run/user/33/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: ""
selinuxEnabled: false
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: 'slirp4netns: /usr/bin/slirp4netns'
version: |-
slirp4netns version 1.0.1
commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
libslirp: 4.4.0
swapFree: 487596032
swapTotal: 536866816
uptime: 66h 14m 26.77s (Approximately 2.75 days)
plugins:
log:
- k8s-file
- none
- passthrough
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries:
localhost:10100:
Blocked: false
Insecure: true
Location: localhost:10100
MirrorByDigestOnly: false
Mirrors: null
Prefix: localhost:10100
store:
configFile: /srv/.config/containers/storage.conf
containerStore:
number: 2
paused: 0
running: 2
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
Version: |-
fusermount3 version: 3.10.3
fuse-overlayfs: version 1.4
FUSE library version 3.10.3
using FUSE kernel interface version 7.31
graphRoot: /srv/.local/share/containers/storage
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 16
runRoot: /run/user/33/containers
volumePath: /srv/.local/share/containers/storage/volumes
version:
APIVersion: 4.0.0-dev
Built: 1644185491
BuiltTime: Sun Feb 6 22:11:31 2022
GitCommit: ab4af502b3f60f891192356eddaa13092f785612
GoVersion: go1.17.6
OsArch: linux/amd64
Version: 4.0.0-devSorry for the long comment, but hopefully this helps. Below are three outputs from Notice that the Registry container processes are created in This still looks like a bug in Podman or at least a limitation of rootless containers.
|
Beta Was this translation helpful? Give feedback.
-
|
Possibly related: rootless-containers/rootlesscontaine.rs#32 |
Beta Was this translation helpful? Give feedback.
-
|
@giuseppe Sorry to bump, but do you have any other ideas? It's not a deal breaker for me, but I think there is a bug here. |
Beta Was this translation helpful? Give feedback.
-
|
I think that what is happening is that Podman automatically creates a new cgroup and moves itself there if the user doesn't own the current cgroup. In your case though, since the cgroup is owned, Podman doesn't create a new cgroup (correctly!) and all the auxiliary processes are created there. You could get rid of |
Beta Was this translation helpful? Give feedback.
-
|
Since this is a configuration question not an issue with Podman, moving to discussion. |
Beta Was this translation helpful? Give feedback.
-
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Firstly, sorry if this is actually a bug in my configuration, systemd, Node.js or something else.
My setup is as follows:
www-data).--net slirp4netns:allow_host_loopback=true.www-data), managed by systemd (e.g.,systemctl --user start webhook.service).Expected Result
When I stop the webhook application on the host the containerized applications are unaffected. The webhook application process has no children and therefore killing it kills no other processes.
Actual Result
When I stop the webhook service on the host several other processes are stopped:
fuse-overlayfsslirp4netnsrootlessportrootlessport-childconmonThis takes the containerized application offline and means further Podman commands fail with:
As expected, Podman starts and later exits when spawned by Node.js. The processes above are not children of the webhook service process (
node), but are in the same cgroup.Speculation
As far as I can tell, one of the following is true:
spawncreates Podman processes in such a way that they are unable to create a new cgroup for a new container.Versions
podman version(built from source)Client: Podman Engine
Version: 4.0.0-dev
API Version: 4.0.0-dev
Go Version: go1.17.6 (from Debian testing)
Git Commit: ab4af50
Built: Sun Feb 6 22:11:31 2022
OS/Arch: linux/amd64
runc --version(from Debian testing)runc version 1.0.3+ds1
commit: 1.0.3+ds1-1
spec: 1.0.2-dev
go: go1.17.4
libseccomp: 2.5.1
crun --version(from Debian stable)crun version 0.17
commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
systemd --versionsystemd 247 (247.3-6)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified
node --versionv16.13.2
podman info --debugPackage info
Podman not installed via package manager.
Beta Was this translation helpful? Give feedback.
All reactions