On Wed, Aug 26, 2015 at 08:00:16PM +0200, Felix Geyer wrote: > > [Service] > > Type=oneshot > > ExecStart=XXX > > ExecReload=XXX > > ExecRestart=XXX > > ExecStop=XXX > > There is no ExecRestart, systemd translates restart to stop/start. > That makes it a bit challenging to have a well-defined reload/restart actions. > > Currently we do this in the init script: > - start: load all profiles > - stop: clear cache > - reload/restart: clear cache, load profiles, unload obsolete profiles > > Why does it clear the cache? Is the cache invalidation known to be > problematic?
I think "stop clears cache" was a bandaid to fix a cache invalidation issue. Since it was so painful, it also had bandaids to try to keep stop from running all that often. Last time I looked into this I was driven to insanity -- especially since it wasn't clear what was historical holdover from ancient civilzations and what was actually necessary today. > Imho ideally we'd do this: > - start/reload: load all profiles, unload obsolete > - stop: nop > > Iirc detecting/unloading obsolete profiles is a bit expensive so we might not > want to do > that on boot though. I don't really like the "unload obsolete" idea much: "the system" policies are in /etc/apparmor.d/. Ubuntu touch / snappy has entire second set of policies for "apps" / "snaps" stored in /var/ somewhere. Perhaps other services exist that generate profiles on the fly or store them somewhere else and unloading them just because they don't also exist in /etc/apparmor.d/ feels like a mistake. Darix mentioned that systemd units can be parameterized; could this functionality be used to load profiles from multiple directories? Does it buy us anything? Thanks
signature.asc
Description: Digital signature