audit_printk_skb slowing down boot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apparmor (Ubuntu) |
Confirmed
|
Low
|
Unassigned |
Bug Description
Subjectively, my system slowed down after the recent GRUB update.
As you can see from the following, audit_printk_skb is consuming a lot of boot time:
[ 13.243280] vboxdrv: Successfully loaded version 4.3.10_Ubuntu (interface 0x001a0007).
[ 13.257947] vboxpci: IOMMU not found (not registered)
[ 13.862999] IPv6: ADDRCONF(
[ 13.865996] IPv6: ADDRCONF(
[ 14.195776] r8169 0000:04:00.0 eth0: link down
[ 14.195796] r8169 0000:04:00.0 eth0: link down
[ 14.195827] IPv6: ADDRCONF(
[ 14.196138] IPv6: ADDRCONF(
[ 15.769090] r8169 0000:04:00.0 eth0: link up
[ 15.769097] IPv6: ADDRCONF(
[ 16.223084] init: plymouth-
[ 42.424836] audit_printk_skb: 195 callbacks suppressed
[ 42.424839] type=1400 audit(143189108
[ 42.424844] type=1400 audit(143189108
[ 42.425185] type=1400 audit(143189108
(END)
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: apparmor 2.8.95~
ProcVersionSign
Uname: Linux 3.13.0-53-generic i686
ApportVersion: 2.14.1-0ubuntu3.10
Architecture: i386
CurrentDesktop: Unity
Date: Fri May 22 14:18:46 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-04-29 (388 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140417)
ProcKernelCmdline: BOOT_IMAGE=
SourcePackage: apparmor
Syslog:
UpgradeStatus: No upgrade log present (probably fresh install)
Changed in apparmor (Ubuntu): | |
importance: | Undecided → Low |
It's highly unlikely that the audit_printk_skb() function is itself slowing down your boot; it is designed to operate with extremely low overhead, and the ratelimiting that is in effect here means that the slowest portion of the function, actually writing characters to the system log, is skipped entirely.
Probably what is actually slow is recompiling AppArmor policies; this is an extremely computational heavy task that has been subject to extensive optimization. We're planning further caching efforts in the future to reduce the number of times that the policies must be recomputed. Chances are quite good a second reboot, immediately after this one, would run faster, since the profiles would probably not need to be rebuilt immediately.
Thanks