I can reproduce this issue repeatedly on Ubuntu 26.04.1 LTS / ARM64 (aarch64) with kernel 7.0.0-42-generic.
Environment: - OS: Ubuntu 26.04.1 LTS (Resolute Raccoon) - Architecture: aarch64 - Kernel: 7.0.0-42-generic - AppArmor: 5.0.2-0ubuntu1~26.04.1 - AppArmor parser: 5.0.2 - K3s: v1.37.1+k3s1 - Container runtime: containerd v2.3.4-k3s1 - CloudNativePG: 1.30.1 - PostgreSQL: 18.6 (standard-trixie) - AppArmor: enabled, enforcing - kernel.apparmor_restrict_unprivileged_userns = 1 - kernel.unprivileged_userns_clone = 1 Reproduction: - Deploy a fresh PostgreSQL 18.6 cluster using CloudNativePG on K3s. - InitDB completes successfully. - PostgreSQL starts and reports "database system is ready to accept connections". - Bootstrap hangs at "Configuring new PostgreSQL instance". - The cluster remains in "Setting up primary" with no ready PostgreSQL instances. PostgreSQL logs: database system is ready to accept connections server started Configuring new PostgreSQL instance Kubernetes status after approximately two minutes: - Cluster: postgresql - Instances: 1 - Ready: 0 - Status: Setting up primary - InitDB Pod: Running - InitDB Job: Running (0/1) - PVC: Bound (local-path) A local PostgreSQL connection inside the InitDB container times out: psql: error: connection to server on socket "/controller/run/.s.PGSQL.5432" failed: timeout expired AppArmor audit logs: The following signal denials occurred during the same PostgreSQL bootstrap attempt on October 31, 2026: - 09:58:39 — comm="manager", signal=urg - 09:58:44 — comm="postgres", signal=usr1 - 09:58:45 — comm="postgres", signal=urg - 09:59:45 — comm="postgres", signal=term All four events reported: apparmor="DENIED" operation="signal" class="signal" profile="cri-containerd.apparmor.d" requested_mask="send" denied_mask="send" peer="cri-containerd.apparmor.d//&unconfined" AppArmor labels inside the affected InitDB container: - /proc/1/attr/current: cri-containerd.apparmor.d//&unconfined (enforce) - /proc/self/attr/current: cri-containerd.apparmor.d//&unconfined (enforce) Additional PostgreSQL diagnostics: 1. Authentication stall (default I/O configuration) GDB backtrace from a blocked PostgreSQL backend: ConditionVariableTimedSleep() WaitReadBuffers() read_stream_next_buffer() heap_getnextslot() systable_getnext() GetSysCacheOid() get_role_oid() hba_getauthmethod() ClientAuthentication() The PostgreSQL asynchronous I/O workers were also waiting in WaitLatch(). 2. Checkpoint stall (io_method=sync) As a diagnostic experiment, PostgreSQL was redeployed with io_method=sync. Bootstrap advanced beyond the authentication stage but stalled at: Executing post-init SQL instructions Executing post-init template SQL instructions Attempting checkpoint before shutdown Executing CHECKPOINT command before shutdown pg_stat_activity showed: - Client backend: IPC / CheckpointStart - Checkpointer: Activity / CheckpointerMain GDB backtraces: - CHECKPOINT backend: RequestCheckpoint() ConditionVariableTimedSleep() WaitLatch() - Checkpointer: CheckpointerMain() WaitLatch() The checkpoint eventually started after approximately 3 minutes and 25 seconds and completed in 86 ms. 3. PostgreSQL signal failure A call to pg_reload_conf() returned: WARNING: failed to send signal to postmaster: Permission denied pg_reload_conf = f The kernel audit log recorded a matching AppArmor denial for signal=hup. Reproducibility: - Reproduced multiple times with fresh PostgreSQL clusters and PVCs. - Default I/O configuration: bootstrap stalls during authentication. - io_method=sync: bootstrap progresses further but stalls during checkpoint processing. - AppArmor signal denials are observed in both scenarios. No AppArmor workaround or kernel downgrade has been applied. An A/B comparison with an older kernel has not yet been performed on this ARM64 system. I can provide additional diagnostics or test a proposed fix if needed. -- 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
