On Mon, 23.05.16 22:52, Christian Boltz (systemd-de...@cboltz.de) wrote: > > It appears to me, that you are trying to map something onto the > > "service" concept, that probably shouldn't really be a service. As > > someone who really doesn't know aa I'd probably suggest to have some > > tool maybe called "aactl" that exposes the various verbs you want as a > > UI, for example "load", "unload", ... And then, add one service to > > load and unload translate to start and stop, and that's was systemd > offers by default. Another verb would be reload, which also exists in > systemd. > > The missing part is a way to control the "restart" behaviour. > > Since I'm not the first one who asks for an ExecRestart - is it really > that hard to implement an ExecRestart= ?
As mentioned in another mail: this would contradict job merging, would contradict the logic that each service invocation gets a pristince exeuction context and is not helpful to users. Sorry. This is a security thing: when a service is restarted no creds from the earlier run should end up in the new process' context. > BTW: Implementing an "aactl" command wouldn't be hard in the technical > sense, but will break existing scripts and user workflows who expect that > AppArmor can be controlled with systemd. How can that be? It never worked with systemd, there never was a way how services could override restart. > And I'm sure people would ask me why I invent a new command instead of > simply using systemd ;-) It doesn't map. And I don't think this really should be mapped to systemd concepts at all. It's skewed. systemd is a service manager, not a policy loading abstraction kit... > > systemd that is of Type=oneshot and RemainAfterExit=yes, and runs > > "ExecStart=/usr/bin/aactl load". But do not misuse this as > > user-facing concept, do not make it do anything on stop or even > > restart, but only use it as a way of hooking aa into the early-boot > > process. Or in other words: make users use "aactl reload" or so, to > > reload their policies, and don't involve systemd in that, except for > > initial policy loading during early boot. > > AppArmor profiles get loaded using initscripts since forever (at least > since I know AppArmor) and now with an apparmor.service file. > Everything worked fine with the initscript, and it also works with > systemd (with the exception we are discussing here). > > I'd really like to keep the apparmor.service instead of inventing my own > command. Well, systemd is not SysV, and your stuff is early-boot and we don't provide compatibility with SysV during early boot anyway. Don't expect that everything should map 1:1 when you port it from sysv to systemd. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
