Hi, On 02/21/2014 11:02 AM, 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).
Honestly, I'm far from being an expert in systemd or in compatibility of systemd with sysvinit. From all the comments in the bugs above I see that there are still some issues with how the init scripts are compatible with systemd and what is needed and what not. I feel that there is lack of complete information on how to control services via systemd correctly and I'm glad that you started this discussion. However, I can't stop asking me the question: how managed package maintainers those systemd issues at other distros?
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".
In Yast the systemd support we currently have is only basic one. Once we know what the best practice in managing systemd units is, we'll implement it as needed.
The proposed new Yast systemd API is not going to be compatible with sysvinit.
But isn't systemd backward compatible with SysVinit?
Yast does nothing special in its internals to support this compatibility. It only relies on the `systemctl` command to do its job (this may change in the future but this is what we have now). The package maintainers are those who are in control of the init scripts functionality and backward compatibility.
I mean what about third-party packages that provide a service but only with /etc/init.d/script?
I hope the third party package maintainers are aware of systemd and do what is necessary for their packages to work correctly (e.g., provide some wrappers for sysvinit scripts to work with systemd).
Would yast2-services-manager work correctly for that?
yast2-services-manager is built on top of `systemctl`. Regards Vlado -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org