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

[intrigeri]

Hi Martin,

Martin Pitt wrote (03 May 2015 08:36:40 GMT) :
> Could we change the scripts to drop xargs? I. e replace constructions
> like "cmd1 | xargs -n1 cmd2" with "for i in `cmd1`; do cmd2 $i; done",
> or "cmd1 | xargs cmd2" with "cmd2 `cmd1`"?

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? :)

* 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 $(...)".

Cheers,
-- 
intrigeri