Mailinglist Archive: yast-devel (53 mails)

< Previous Next >
Re: [yast-devel] What means calling Service.[Start|Stop|Enable|Disable]("foo")?
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@xxxxxxxx)
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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups