Hello, On Feb 20 17:16 Vladimir Moravec wrote (excerpt):
On 02/20/2014 03:13 PM, Johannes Meixner wrote:
does calling Service.[Start|Stop|Enable|Disable]("foo") mean only foo.service gets started/stopped/enabled/disabled?
Correct.
O.k. That matches my observation in https://bugzilla.novell.com/show_bug.cgi?id=857372#c115 and proves my conclusion in https://bugzilla.novell.com/show_bug.cgi?id=857372#c120 and shows that https://bugzilla.novell.com/show_bug.cgi?id=800492 was not fixed - respectively that https://bugzilla.novell.com/show_bug.cgi?id=799471 (closed as WORKSFORME on 2013-11-22 18:52:10 CET by max@suse.com) does not work - not for me and probably also not for others (no surprise when YaST core issues get lost in useless discussions).
I would expect that calling Service.[Start|Stop|Enable|Disable]("foo") means "the whole 'foo' thing" (both foo.service and foo.socket) while calling Service.[Start|Stop|Enable|Disable]("foo.service") means only foo.service (but not foo.socket).
The systemd API calls are going to change. There is a proposal for socket unit manipulation currently in review [1] (feel free to comment there), other units will follow. The proposed API will look like this:
foo = SystemdSocket.find 'foo' foo.stop # if we have a socket-activated service, it will stop now
[not yet implemented] bar = SystemdService.find 'bar' bar.disable
I'm not sure about the API call for "the whole thing" as you mentioned above, it might be confusing and unpredictable. There is no plan to design it like that. If there are some dependencies among systemd units, they should be expressed inside the unit files.
Regarding "the whole thing" see https://bugzilla.novell.com/show_bug.cgi?id=864894 systemd unit files: RFC: provide "superset"/"master" unit files for services Meanwhile I think any kind of find/search/regex as an attempt to somehow deal with "the whole thing" cannot work because no tool can know in advance what to find/search for i.e. how the systemd units are called that belong to "the whole thing" and I agree that this way it must get confusing and unpredictable. As far as I understand systemd (I am not at all a systemd expert) it would be perfectly o.k. when the admin replaces SUSE's systemd unit files foo.service and foo.socket with his own systemd unit files using a totally differnt naming schema (e.g. according to his particular site policies) like acme_something.service and acme_something.socket. Then again YaST would fail (as it fails currently). In contrast if "superset"/"master" unit files are possible and if SUSE provided a foo.master unit file for "the whole foo thing" and if YaST would use such a master unit file (if exists) and if SUSE would even document its usage properly, then an admin who likes to have his own systemd unit files would know that he must keep and adapt the foo.master unit file if he wants that YaST still works for "the whole foo thing".
The proposed new Yast systemd API is not going to be compatible with sysvinit.
But isn't systemd backward compatible with SysVinit? I mean what about third-party packages that provide a service but only with /etc/init.d/script? Would yast2-services-manager work correctly for that? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org