[systemd-devel] restart vs. stop/start
Lennart Poettering
lennart at poettering.net
Tue May 24 10:02:09 UTC 2016
On Mon, 23.05.16 22:52, Christian Boltz (systemd-devel at 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
More information about the systemd-devel
mailing list