Hello, Am Montag, 19. Januar 2015 schrieb Andrei Borzenkov:
В Mon, 19 Jan 2015 18:19:11 +0100 Christian Boltz <opensuse@cboltz.de> пишет:
Seriously: I can think of an easy and obvious solution - the wrapper should just hand over the parameter it gets to the initscript without any modification. This means: systemctl foo restart -> /etc/init.d/foo restart
systemd does not have notion of "restart" as first class citizen. It implements "restart" as "stop" followed by "start".
As default behaviour for *.service files, there's nothing wrong with that. Note that there's ExecRestart to override it. So the systemd developers know that it most be possible to override the behaviour for "restart". One more reason to allow an initscript to override it ;-)
instead of the current, broken behaviour
All initscripts I am aware of implement "restart" as "stop" followed by "start".
Then you don't know all initscripts ;-) - I'm quite sure there were or are more initscripts that have a different behaviour for restart. The point is that initscripts are shell code, which means they can do *whatever they want* - as an extreme example, "rcfoo restart" could play some music (I don't say that's a good idea, but it's possible.) Back to the serious part - doing something in a way that makes sense and avoids problems (for example not dropping AppArmor protection from running processes) is worth more than strictly following what LSB describes. The AppArmor initscript is not 100% LSB compliant because it maps restart to reload? Thanks for the information, but my server is still protected. (Well, at least if I use SYSTEMD_NO_WRAP=1.) I'm quite sure everybody prefers that over the correct implementation of restart as "stop, then start".
I very seriously doubt anyone will spend time for the sake of single script that decided to interpret it differently. May be this script actually misuses "restart" for "reload" here? I'm guessing - bug is non public ...
Systemd promised to support initscripts. For me, that includes support for slightly unusual initscripts. Part of this is to hand over parameters as specified ("restart") and not changed to something that looks right in most cases.
Ah, OK. As I suspected:
restart|reload|force-reload)
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less."
Now let's think about what users want/expect when they call "rcapparmor restart": a) load updated profiles and keep running processes protected b) load updated profiles and remove protection from all running processes Yes, I'd like to hear a serious answer on this.
I guess, the obvious answer is - do not use %restart_on_update boot.apparmor in spec file, explicitly use "systemctl reload". We obviously have service whose behavior is very different to others, so it is logical to deviate from defaults.
I already do this in the rpm %post script - but still, there might be users who might (maybe "just" accidently) use "rcapparmor restart" instead of "rcapparmor reload". Regards, Christian Boltz PS: Fun fact: ExecStatus is not implemented, but it works when using an initscript. This means "systemctl status apparmor" is much more useful now than it would be after migrating to an apparmor.service. --
babelfish could be your friend here Have you tried it? It usually translates about as well as a drunken 2 year old! :-P [> scsijon and David Wright in opensuse]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org