Am 12.01.2016 um 19:44 schrieb Lennart Poettering:
On Tue, 12.01.16 19:37, Reindl Harald (h.reindl@xxxxxxxxxxxxx) wrote:That said, of course, this is not obvious at first, hence since quite some time "systemctl stop" will actually explain this to you: if you stop a daemon, but leave its socket running, then you'll get a friendly message telling you about this, and suggesting you the right command line to terminate the socket too.as soon as you are able to print out such a "friendly message" you are also able to imply it automaticallyWell, sure, but that's something we don't want to do, as people should be able to stop units and their triggering units separately and individually. I'd be willing to take a patch that adds a new job mode though, that recursively includes stop/start jobs for all triggering units. i.e. "systemctl --job-mode=triggering foo.service" or so. That would certainly be a useful enhancement, but should not be the default.
IT SHOULD be the defaultwhen i say "systemctl stop service" i mean that unconditionally and there is no point in for example stop a webserver manually while the socket would fire up the service on the next request
there is *really* no point for such a behavior
I am pretty sure this makes a lot of sense the way it is, and is sufficiently well self-explanatory.no, it violates the prnciple of least surprise and that won't changeWell, let's agree to disagree on this one
well, than accept that i refuse to use socket activated services and recommend that to anybody else until bheavior changes
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
