Bug 1093029 - [Build 20180511] openQA test fails in yast2_dns_server - "named.service is not active, cannot reload."
[Build 20180511] openQA test fails in yast2_dns_server - "named.service is no...
Status: VERIFIED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Stefan Schubert
Jiri Srain
https://openqa.opensuse.org/tests/674...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-05-12 12:59 UTC by Oliver Kurz
Modified: 2018-09-17 14:16 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Kurz 2018-05-12 12:59:20 UTC
## Observation

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-yast2_ncurses@64bit fails in
[yast2_dns_server](https://openqa.opensuse.org/tests/674858/modules/yast2_dns_server/steps/44)
because the "named" service is not active after the yast configuration part exits.

Error output from y2log:

```
2018-05-12 04:07:39 <1> susetest(24233) [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-12 04:07:39 <1> susetest(24233) [Ruby] yast2/systemctl.rb:32 systemctl reload named.service 
2018-05-12 04:07:39 <3> susetest(24233) [bash] ShellCommand.cc(shellcommand):78 named.service is not active, cannot reload.
```


## Reproducible

Failed already two times in the snapshot in before the "last good", 20180508. I assume it is sporadic.


## Expected result


The service should be running at the time of exiting the yast configuration part as was the case in before

Last good: Build [20180510](https://openqa.opensuse.org/tests/674165#step/yast2_dns_server/10)

### Problem

Could be that the service would actually be running after some waiting time. I will see what we can do to improve the investigation in the test itself to find out more information.


## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?version=Tumbleweed&distri=opensuse&arch=x86_64&flavor=DVD&test=yast2_ncurses&machine=64bit)
Comment 1 Oliver Kurz 2018-05-12 13:02:50 UTC
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.
Comment 2 Stefan Schubert 2018-05-24 10:53:20 UTC
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 !
Comment 3 Oliver Kurz 2018-05-24 20:17:27 UTC
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.
Comment 4 Stefan Schubert 2018-05-30 07:53:39 UTC
(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
Comment 5 Martin Loviska 2018-05-31 07:44:04 UTC
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.
Comment 6 Stefan Schubert 2018-06-04 08:56:27 UTC
submitted. Lets see if openQA is happy now :-)
Comment 7 Swamp Workflow Management 2018-06-05 15:11:45 UTC
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
Comment 8 Oliver Kurz 2018-06-06 06:09:02 UTC
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?
Comment 9 Stefan Schubert 2018-06-13 12:24:49 UTC
(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.
Comment 10 Oliver Kurz 2018-06-13 13:24:55 UTC
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"?
Comment 11 Stefan Schubert 2018-06-13 15:05:11 UTC
(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 ?
Comment 14 Josef Reidinger 2018-08-22 14:02:40 UTC
jiri ping
Comment 15 Jiri Srain 2018-08-29 12:46:55 UTC
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.
Comment 16 Stefan Schubert 2018-09-17 08:58:01 UTC
(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...
Comment 17 Oliver Kurz 2018-09-17 14:16:04 UTC
ok, thx for clarifying if the current behaviour is acceptable.