On 2025-11-10 21:29:06 +0100, Christian Boltz wrote: > Am Montag, 10. November 2025, 04:29 schrieb Vincent Lefevre: > > [ *] Job apparmor.service/start running (16s / no limit) > > Just to clarify/exclude the most obvious possibe reason: > > Do you see this long start time with _every_ boot of the new kernel, or > was it only on the first boot after the kernel update?
This is not reproducible, not even after another kernel update (6.17.7+deb14+1-amd64). > (If it was only during the first boot after the kernel update, that's > probably because the profile cache was rebuilt for the new kernel.) When is the profile cache rebuilt? Why didn't this occur in the past after kernel upgrades? For the concerned boot, the unfiltered journalctl output gives [...] Nov 07 17:40:29 cventin systemd[1]: Starting systemd-sysctl.service - Apply Kernel Variables... Nov 07 17:40:29 cventin systemd[1]: Finished systemd-sysctl.service - Apply Kernel Variables. Nov 07 17:40:46 cventin kernel: kauditd_printk_skb: 111 callbacks suppressed Nov 07 17:40:46 cventin kernel: audit: type=1400 audit(1762533646.806:123): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-soffice" pid=787 comm="apparmor_parser" Nov 07 17:40:46 cventin kernel: audit: type=1400 audit(1762533646.814:124): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-soffice//gpg" pid=787 comm="apparmor_parser" Nov 07 17:40:46 cventin systemd[1]: Finished apparmor.service - Load AppArmor profiles. [...] One can see 17 seconds with no messages in the logs. I don't know whether this could be related to the issue, but these "audit" lines about libreoffice-soffice normally do not appear during the boot. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
