Also there are error messages in the y2log file but they do not seem to be directly related as they also appear in the last good. Still, they should be prevented:

* "Error output: firewallctl is deprecated and will be removed in a future release" -> This most likely was introduced with https://bugzilla.suse.com/show_bug.cgi?id=1084026 which is describing a firewalld update to a more recent version late during SLE15 development
* "modules/Wizard.rb:830 Unknown option `shrinkable in RadioButtonGroup widget" -> I guess on critical for functionality
* "ShellCommand.cc(shellcommand):78 named.service is not active, cannot reload." -> Also appears in last good

If anyone prefers I can report individual bug reports about these.

Hm, I cannot reproduce the error with:
openSUSE-Tumbleweed-DVD-x86_64-Snapshot20180521-Media.iso

The named.service is in bind package.
Could you please check it again with the latest build ? Thanks !

openQA did this job for us :) The latest result show a failure again: https://openqa.opensuse.org/tests/682121

As stated in the description: It's a sporadic issue. I assume the problem can not be reproduced manually by simply looking for the service to be running after some seconds. I assume when you want to check *manually* then you need to call "yast2 dns_server; systemctl is-active named" so that the systemctl call is immediately executed after exiting the yast2 module.

(In reply to Oliver Kurz from comment #3)
> openQA did this job for us :) The latest result show a failure again:
> https://openqa.opensuse.org/tests/682121

Good point :-)

> 
> As stated in the description: It's a sporadic issue. I assume the problem
> can not be reproduced manually by simply looking for the service to be
> running after some seconds. I assume when you want to check *manually* then
> you need to call "yast2 dns_server; systemctl is-active named" so that the
> systemctl call is immediately executed after exiting the yast2 module.
Ah, ok. I have seen this too sometime ago. The server has been in state "starting" in that case. Hopefully this works:
https://github.com/yast/yast-dns-server/pull/68

Hello Stefan, Oli!

I think the issue was in our test module, which trying to configure DNS while yast2 is loading default data for this screen.
https://openqa.suse.de/tests/1735678#step/yast2_dns_server/8
If you look at the fw port settings, it states that the port is opened, but in fact it is not at all.
Following screen displays the real state of FW port.
https://openqa.suse.de/tests/1735678#step/yast2_dns_server/9

I have introduced 2 needles which should prevent situation that we are pressing keystrokes while yast2 is loading its default settings.

submitted. Lets see if openQA is happy now :-)

This is an autogenerated message for OBS integration:
This bug (1093029) was mentioned in
https://build.opensuse.org/request/show/614326 15.0 / yast2-dns-server

Sorry, that does not seem to help: https://openqa.suse.de/tests/1746930#step/yast2_dns_server/37 is the latest SLE15 GMC_C5 build 665.1 failure. Could you please take a look again?

(In reply to Oliver Kurz from comment #8)
> Sorry, that does not seem to help:
Np :-)

Well from my point of view it is working now correctly:

Before the fix "reload" has been called:

2018-05-24 16:11:34 <1> susetest(24298) [Ruby] yast2/systemctl.rb:32 systemctl reload named.service 
2018-05-24 16:11:34 <3> susetest(24298) [bash] ShellCommand.cc(shellcommand):78 named.service is not active, cannot reload.
2018-05-24 16:11:34 <1> susetest(24298) [Ruby] yast2/systemctl.rb:32 systemctl show named.service  --property=Id  --property=MainPID  --property=Description  --property=LoadState  --property=ActiveState  --property=SubState  --property=UnitFileState  --property=FragmentPath 
2018-05-24 16:11:34 <1> susetest(24298) [Ruby] clients/dns-server.rb:38 DnsServer module finished

After the fix "restart" has been called:

2018-06-05 19:38:00 <1> susetest(10559) [Ruby] yast2/systemctl.rb:32 systemctl restart named.service 
2018-06-05 19:38:00 <1> susetest(10559) [Ruby] yast2/systemctl.rb:32 systemctl show named.service  --property=Id  --property=MainPID  --property=Description  --property=LoadState  --property=ActiveState  --property=SubState  --property=UnitFileState  --property=FragmentPath 
2018-06-05 19:38:00 <1> susetest(10559) [Ruby] clients/dns-server.rb:38 DnsServer module finished

Yes, it will take a while to restart the service. So I am assuming that's the reason for your failing check script.

Sure so maybe it helped but the original issue was that the named service is not ensured to be active after the yast configuration part exits. I do not know what the generic approach for the service related yast configuration parts is: Should the services ensured to be running at exit-time or just ensured to be "triggered to start"?

(In reply to Oliver Kurz from comment #10)
> Sure so maybe it helped but the original issue was that the named service is
> not ensured to be active after the yast configuration part exits. I do not
> know what the generic approach for the service related yast configuration
> parts is: Should the services ensured to be running at exit-time or just
> ensured to be "triggered to start"?

Well, at least we have a running service now with the values changed in
the YAST module. I am not so sure if it is so important that the service is
running straight after the YAST module has been finished but after about 5 seconds. I think that is acceptable :-)

Jiri, what do you think ?

jiri ping

I agree, if it is about a few seconds, it should not be a big deal.

I still can remember a service which - in some cases - needed minutes to start (cups had to do initial build of its database).

As long as systemctl call suceeds, YaST has no control over what is going on. If it really is an issue, than IMO the systemctl call should wait until the service is operational.

Ensuring a service is operational could result in an infinite wait - imagine that it crashed between starting and the check itself.

(In reply to Jiri Srain from comment #15)
> I agree, if it is about a few seconds, it should not be a big deal.
> 
> I still can remember a service which - in some cases - needed minutes to
> start (cups had to do initial build of its database).
> 
> As long as systemctl call suceeds, YaST has no control over what is going
> on. If it really is an issue, than IMO the systemctl call should wait until
> the service is operational.
> 
> Ensuring a service is operational could result in an infinite wait - imagine
> that it crashed between starting and the check itself.

Thanks. So I will close it again...

ok, thx for clarifying if the current behaviour is acceptable.