Public bug reported:
After the update from linux-oracle 7.0.0-1013.13 to 7.0.0-1015.16
(Ubuntu 26.04 resolute, Oracle Cloud Ampere A1, arm64), every Kubernetes
(k3s v1.36.5+k3s1, containerd/runc 1.4.2) pod whose entrypoint uses gosu
(official postgres and mysql images) hangs forever at 60-100 % CPU and
the database never starts. Booting 7.0.0-1013-oracle again fixes it.
Reproduced on two separate hosts.
Process label of a pod process:
- 7.0.0-1013-oracle: `cri-containerd.apparmor.d (enforce)`
- 7.0.0-1015-oracle: `cri-containerd.apparmor.d//&unconfined (enforce)`
The 1015 changelog contains "apparmor: fix unconfined user namespace
restriction forced stack", which is the likely origin of the new stacked
label.
gosu (1.19, go1.24.6) calls syscall.Setgid. In a multi-threaded Go
program this goes through syscall.AllThreadsSyscall: the runtime sends a
signal to each thread of the process and waits in a sched_yield loop
until every thread has run the syscall. Under the stacked label the
signal to the sibling threads appears to be dropped; no
apparmor="DENIED" message is logged. The sibling threads stay in
futex_wait and the main thread spins forever.
perf record -g -p <pid> on the hung process:
schedule <- do_sched_yield <- __arm64_sys_sched_yield <- invoke_syscall <-
el0_svc <- el0t_64_sync
runtime.osyield.abi0
syscall.runtime_doAllThreadsSyscall
syscall.AllThreadsSyscall
syscall.Setgid
main.SetupUser
main.main
/proc/<pid>/status: Threads 5 (main R, others S in futex_wait),
SigPnd/ShdPnd 0, SigBlk 0, Seccomp 0, nonvoluntary_ctxt_switches in the
billions.
Steps to reproduce (on 7.0.0-1015-oracle, arm64, k3s)
k3s kubectl run gt -n default --restart=Never --image=postgres:16-alpine
--command -- gosu postgres true
Expected: the pod completes in under a second (as on 7.0.0-1013-oracle).
Actual: the pod stays Running, gosu at ~100 % CPU indefinitely.
Repro matrix on 7.0.0-1015 (same image, identical gosu binary)
- k3s pod, default AppArmor profile (`cri-containerd.apparmor.d//&unconfined`):
hangs
- k3s pod, securityContext.appArmorProfile RuntimeDefault: hangs
- k3s pod, securityContext.appArmorProfile Unconfined: OK
- docker run (label `docker-default`, not stacked): OK
- k3s ctr run (no AppArmor profile): OK
- host, `gosu nobody true` 750 times, also under CPU contention: 0 hangs
Environment
- Ubuntu 26.04 (resolute), linux-image-oracle 7.0.0-1015.16 (arm64), Oracle
Cloud VM.Standard.A1.Flex, 2 OCPU
- kernel.apparmor_restrict_unprivileged_userns = 1,
kernel.apparmor_restrict_unprivileged_unconfined = 1
- k3s v1.36.5+k3s1 (bundled containerd, runc 1.4.2); Docker 29.x for comparison
- Workaround in use: boot 7.0.0-1013-oracle (GRUB_DEFAULT)
** Affects: linux-oracle (Ubuntu)
Importance: Undecided
Status: New
** Tags: apparmor arm64 regression-update resolute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172531
Title:
linux-oracle 7.0.0-1015: AppArmor forced stack breaks signals between
threads in containerd (k3s) containers; Go programs hang in setgid
(gosu)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/2172531/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
