Mailinglist Archive: yast-devel (53 mails)

< Previous Next >
Re: [yast-devel] What means calling Service.[Start|Stop|Enable|Disable]("foo")?


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?



That matches my observation in
and proves my conclusion in
and shows that
was not fixed - respectively that
(closed as WORKSFORME on 2013-11-22 18:52:10 CET by max@xxxxxxxx)
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'

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
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

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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups