[pkg-apparmor] Bug#782700: Bug#782700: Bug#782700: Please drop $remote_fs init.d dependency to allow running early

[Seth Arnold]

On Sun, May 03, 2015 at 01:32:48PM +0200, intrigeri wrote:
> I see xargs used for a few different purposes in
> debian/lib/apparmor/functions:
> 
> * when compiling the policy from scratch, e.g. on Live systems:
>   with -n1 -P, so that all CPU cores are used; in this case, simply
>   dropping xargs would imply a significant boot time increase for SMP
>   systems that have no cache. E.g. on my Tails/Jessie VM, the apparmor
>   service startup takes 13s with one single core, and 7s with two
>   cores (note that we've removed the $remote_fs dependency a while ago
>   in Tails/Jessie already). I'd rather avoid taking that performance
>   hit, and I can think of two potential solutions:
> 
>   - long-term: Live systems should ship a cached pre-compiled policy,
>     as is done for the Ubuntu phone. My understanding is that this
>     requires the ISO build system to run the exact same kernel as the
>     one shipped inside the ISO, which is quite impractical.
> 
>   - short-term: instead of "xargs -n1 -P", we could use busybox'
>     xargs; it doesn't support -P, so we need to manually compute the
>     optimal -n parameter (number of profiles / number of CPU cores).
> 
>   Thoughts, opinions, patches? :)

Having the parser handle its own parallelism has been on our backburner
for a long time; calling the parser once per directory with profiles is
the end goal, e.g. apparmor_parser --replace /etc/apparmor.d/
(This works now, just without DTRT parallelism.)

The "exact same kernel" has been relaxed recently, either --match-string
or --features-file or both ought to let a new-enough parser generate
"correct" policy for a given target kernel using any other kernel. This
could allow precompiling on the build hosts.

> * when refreshing the policy cache: with -P only, so likely only one
>   apparmor_parser is run, and then dropping xargs shouldn't change
>   anything.
> 
> * in clear_cache(), that's used by the init script's start action when
>   the policy was updated. Here, we could indeed call "rm $(...)"
>   instead, but then we would lose the benefits from the nice
>   "find -print0 | xargs -0" pattern. OTOH, the cache directories are
>   only writable by root, so in this case it should be safe to simply
>   use "rm $(...)".

Recent gnu find supports -delete and avoids the fork()/exec() entirely.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-apparmor-team/attachments/20150504/142235ee/attachment.sig>