On Sun, Dec 25, 2011 at 7:50 PM, Graham Anderson firstname.lastname@example.org wrote:
On Sunday 25 Dec 2011 15:52:47 Claudio Freire wrote:
You've been given examples of services that aren't either daemons or where a "standard code" is an oversimplification.
I reject the premise of this argument. AppArmor is implemented as kernel code and as such is pretty much the definition of a daemonised service. That the profiles are injected sequentially via scripts is probably in itself more a clue about AppArmors design than anything else.
So what? Does that make it pointless to query AppArmor's status? Does the fact that its status depends on which profiles are loaded is immaterial? Does that design make it irrelevant to know which profiles are laded when querying status?
I say if you say "No" to any of those questions, you're just shooting yourself in the foot.
If it were pointless to query AppArmor's status, then it's pointless to have it. Many servers run 365/24/7, and that means there's lots of ways in which profiles can be unloaded and a reboot is not an option. If you "just assume it's running" because "I started it", then you're simply wrong. Querying status here is an important sysadmin tool.
Same applies to knowing which profiles have been loaded. One profile being unloaded isn't the same as the whole service being down, so it's an important distinction.
If you ignore it, there's no much point in issuing an RFC I guess.
RFC is not "tell me every little detail you want included". It's a polite way of hearing arguements. *Any and all* of which *may and can* be ignored, excluded, argued against of even ridiculed.
The point of an RFC is hearing arguments. The OP doesn't seem to be hearing.
The _request for comments_ has highlighted one area where systemd doesn't seem to have a remit or functionality to deal with. I would argue that this is more a problem of AppArmor using sysvinit as convenience than anything that systemd should even be concerned with.
The RFC has already at least one sysadmin commenting on how that "convenience" is good. I can subscribe to that. If the OP ignores this, because systemd doesn't have the functionality and we *must* switch to systemd, then I say it's a backwards proposition. systemd has to serve sysadmins, not the other way around.
So, you say it's an issue with AppArmor (and all other services that do so, like VMs, postgres, and who knows how many more). I say it's an issue with systemd, it's not functional enough to replace systemv yet.
It's a simple functionality. It's just capturing the output of initscripts, and allowing native modules to produce output. I don't think it's so much to ask.