Hi, On 02/20/2014 03:13 PM, Johannes Meixner wrote:

Hello,

when there is one service foo with two systemd unit files foo.service and foo.socket and a YaST module calls Service.Enable("foo") Service.Start("foo") Service.Stop("foo") Service.Disable("foo") what is each call meant to result in the system?

Service.Enable("foo") is equivalent to `systemctl enable foo.service`

Does calling Service.[Start|Stop|Enable|Disable]("foo") mean both foo.service and foo.socket get started/stopped/enabled/disabled

No.

or does calling Service.[Start|Stop|Enable|Disable]("foo") mean only foo.service gets started/stopped/enabled/disabled?

Correct.

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.

See in particular https://bugzilla.novell.com/show_bug.cgi?id=800492#c8 that reads [it was YCP at that time (openSUSE 12.3)] (excerpt): ----------------------------------------------------------------------- ... the YCP call Service::Stop("foo") should completely stop those service in all ways how those service can be active or semi-active via systemd.

This way Service::Stop("foo") would work for systemd in compliance how it worked all the time for SysVinit and all YaST modules that use Service::Stop("foo") would work the same for systemd and SysVinit.

In contrast if Service::Stop("foo") only stops foo.service but not foo.socket, foo.path (and all other possible ways which may exist in systemd), then Service::Stop("foo") would be basically useless functionality for systemd because if e.g. foo.socket is still active, any normal user can activate the service by triggering systemd via the socket -----------------------------------------------------------------------

The proposed new Yast systemd API is not going to be compatible with sysvinit. Regards Vlado [1] https://github.com/yast/yast-yast2/pull/180 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

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

Hi, On 27.2.2014 12:26, Johannes Meixner wrote:

Hello,

On Feb 24 11:10 Vladimir Moravec wrote (excerpt):

...

Honestly, I'm far from being an expert in systemd

Neither am I.

...

...

However, I can't stop asking me the question: how managed package maintainers those systemd issues at other distros?

I do not understand the question because other distros do not use YaST as end-user frontend to manage services.

I was rather referring to the superset/master unit files.

When using plain systemctl it works of course also for complicated systemd units with several unit files.

...

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.

This again matches perfectly my observation and accordingly it is currently exactly "the right thing" to get systemd support for a service "foo" that actually works in our current environment to provide only one single systemd unit file foo.service (and nothing else, particular no foo.socket or foo.path and so on).

I was of similar opinion, however after discussing an yast iscsi client issue here [1] I think those other units have its place.

...

yast2-services-manager is built on top of `systemctl`.

I don't know about yast2-services-manager details but I think if yast2-services-manager is basically only a GUI for systemctl then yast2-services-manager would be insufficient to be a really useful end-user frontend to manage services because plain systemctl is too low level.

We had two options of how to control systemd from within yast, either through systemctl or through dbus directly. Currently we rely on using systemctl by calling its unit control commands and parsing their output. I think for the user experience it is not important whether this is low level or not, the UI makes it easier for yast users to control services and prevents them from diving into systemd stuff. There is already discussion going on [2] if the current UI is sufficient, but this is different subject from this thread I guess. Regards Vlado [1] https://bugzilla.novell.com/show_bug.cgi?id=853300 [2] https://bugzilla.novell.com/show_bug.cgi?id=863333 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org