Your message dated Thu, 04 Dec 2025 19:02:43 +0100
with message-id <87345qktvf.fsf@manticora>
and subject line Re: [pkg-apparmor] Bug#1120454: apparmor.service takes time to
finish with the 6.17.6+deb14-amd64 kernel
has caused the Debian Bug report #1120454,
regarding apparmor.service takes time to finish with the 6.17.6+deb14-amd64
kernel
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1120454: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120454
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: apparmor
Version: 4.1.0-1
Severity: normal
X-Debbugs-Cc: [email protected]
User: [email protected]
Usertags: amd64
With the 6.17.6+deb14-amd64 kernel, apparmor.service takes time
to finish: when I booted, I got a message of the form
[ *] Job apparmor.service/start running (16s / no limit)
$ journalctl --no-pager -b -u apparmor.service
Nov 07 17:40:26 cventin systemd[1]: Starting apparmor.service - Load AppArmor
profiles...
Nov 07 17:40:26 cventin apparmor.systemd[624]: Restarting AppArmor
Nov 07 17:40:26 cventin apparmor.systemd[624]: Reloading AppArmor profiles
Nov 07 17:40:46 cventin systemd[1]: Finished apparmor.service - Load AppArmor
profiles.
So it took 20 seconds.
As a comparison, with the 6.16.12+deb14+1-amd64 kernel, I had
$ journalctl --no-pager -b -1 -u apparmor.service
Oct 30 14:48:36 cventin systemd[1]: Starting apparmor.service - Load AppArmor
profiles...
Oct 30 14:48:36 cventin apparmor.systemd[706]: Restarting AppArmor
Oct 30 14:48:36 cventin apparmor.systemd[706]: Reloading AppArmor profiles
Oct 30 14:48:36 cventin systemd[1]: Finished apparmor.service - Load AppArmor
profiles.
(and this was similar with the previous kernels).
-- System Information:
Debian Release: forky/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.17.6+deb14-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apparmor depends on:
ii debconf [debconf-2.0] 1.5.91
ii libc6 2.41-12
apparmor recommends no packages.
Versions of packages apparmor suggests:
pn apparmor-profiles-extra <none>
pn apparmor-utils <none>
-- debconf information:
apparmor/homedirs:
--
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)
--- End Message ---
--- Begin Message ---
Hi,
Thank you Christian for explaining what's going on :)
I'm closing this bug: the package is working as intended here.
One potential UX improvement, derived from a suggestion from Vincent,
is this: when we know we're going to do a full cache build, i.e.
when the cache sub-directory for the current kernel×policy feature set
does not exist, we could say so in the logs. This could be a useful
feature request upstream. I would classify this as "low priority, good
are patches welcome" given IIRC it's the first time, since I'm working
on AppArmor in Debian, that someone complains about this.
Cheers,
--
intrigeri
--- End Message ---
