[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