Same regression here, on a single-node K3s server upgraded from 24.04 to Ubuntu 26.04.1. 7.0.0-42 is bad, 7.0.0-38 is good.
Setup - Ubuntu 26.04.1 LTS (do-release-upgrade from 24.04), amd64 - K3s v1.36.5+k3s1, containerd v2.3.4-k3s1.36 (default cri-containerd.apparmor.d profile) - CloudNativePG operator 1.30.1, PostgreSQL 18.6 (also seen with 18.0) - apparmor 5.0.2-0ubuntu1~26.04.1, kernel.apparmor_restrict_unprivileged_unconfined=1, kernel.apparmor_restrict_unprivileged_userns=1 7.0.0-42 (#42-Ubuntu SMP PREEMPT_DYNAMIC Thu Oct 15 08:06:44 UTC 2026) - After an unclean shutdown, PostgreSQL waits exactly 5:00 for the end-of-recovery checkpoint (e.g. start 13:55:16, "checkpoint starting: end-of-recovery" at 14:00:16; reproduced three times to the second). WAL replay itself takes 0.00 s. - While it waits, the startup process is in epoll_wait with an infinite timeout and the checkpointer is in epoll_wait with a 300000 ms timeout (= checkpoint_timeout), so only the timer wakes it. About 100 local connections pile up in "startup" state until "too many clients". - Audit log on one boot: 352 denials in 6 minutes (other 7.0.0-42 boots: 3507, 722, 934). signal=urg 215, term 134, usr1 3, all with profile="cri-containerd.apparmor.d" peer="cri-containerd.apparmor.d//&unconfined". Senders (comm): postgres 290, manager 14, alloy 10, metrics-server 8, cilium-operator 8, helm-operator 5, hubble-relay 4, node_exporter 3, coredns 2, AdGuardHome 2. So it is not limited to PostgreSQL (Go programs use SIGURG for preemption, I did not measure the impact). - /proc/<pid>/attr/current of the PostgreSQL checkpointer: "cri-containerd.apparmor.d//&unconfined (enforce)". - A start after a clean shutdown was fast (3 s), presumably because it does not rely on those wake-ups. - gosu (Go) also spins at 100% CPU for 4+ minutes in a plain postgres:18 pod, as in LP #2172422. 7.0.0-38 (#38-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 4 09:10:14 UTC 2026), same hardware and config - 0 AppArmor signal denials, label "cri-containerd.apparmor.d (enforce)", no 5-minute wait, all pods healthy. - 24.04's 6.8.0-147 is also fine (0 denials, end-of-recovery checkpoint in 2 s). Changelog Between 7.0.0-38 and 7.0.0-42 the only AppArmor entry matching the symptom is "apparmor: fix unconfined user namespace restriction forced stack" (CVE-2026-90231), part of the upstream stable patchset 2026-10-05 (LP: #2169638) in 7.0.0-41. 7.0.0-42.42 itself only contains a powerpc revert. I did not bisect (7.0.0-41 is not in the archive) and I did not test the apparmor_restrict_unprivileged_unconfined=0 workaround. Is a fix planned for 7.0.0-43 or later? Happy to test a candidate kernel. ** CVE added: https://cve.org/CVERecord?id=CVE-2026-90231 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2172640 Title: Regression in 7.0.0-42: AppArmor forced "//&unconfined" stack on container processes blocks signals between them (PostgreSQL hangs) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172640/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
