OpenSuse Leap 15.1 - NFS status error

phillxnet · April 13, 2020, 5:23pm

Thanks for the reports, all useful stuff.

Could you clarify what you mean by:

By open do you mean enabled. We generally use systemd commands to start / stop services and a variety of mechanisms, depending on the service, to assess if current state. But again it’s mostly systemd commands but from your report some of these look to be switching whatever service state is found which is obviously not correct. But given we haven’t had this reported before it’s a little strange as there is little difference in these regards between our CentOS base and the ‘Built on openSUSE’ endeavour.

Curious.

From memory the restore service state mechanism is meant to only enable a service if that service was previously enabled when the config was saved. The service state restore mechanism was last updated on 3.9.2-51:

[Config Backup/Restore] Restore Service status. Fixes #2087 @FroggyFlox

So taking a look at that issue and it’s linked pull request should lead to the related code. And a glance at the following file:

github.com

rockstor/rockstor-core/blob/master/src/rockstor/system/services.py#L124-L143


      
                  stop = False
                  for line in sfo.readlines():
                      if re.match("\[program:{}\]".format(service), line) is not None:
                          start = True
                      elif start is True and len(line.strip()) == 0:
                          stop = True
          
                      if start is True and stop is False:
                          if re.match("autostart", line) is not None:
                              tfo.write("autostart={}\n".format(switch))
                          else:
                              tfo.write(line)
                      else:
                          tfo.write(line)
              shutil.move(npath, SUPERVISORD_CONF)
          
          
          def superctl(service, switch):
              out, err, rc = run_command([SUPERCTL_BIN, switch, service])
              set_autostart(service, switch)

should give an indication of the triggers used to inform the Web-UI switch reports of service status. The intention is that the system is the single point of truth for service state and we update the db wheneve the page is refresh with the state as reported at the lowest level from the above file’s various mechanism.

Definitely worth taking a look if you fancy as it’s all pretty readable and we do have some switching functions in there that may be the root of this behaviour. I.e. we me be inadvertently switching something when we should be explicitly enabling / disabling. But again we haven’t had reports of this, at least in more recent years. So this out-of-sync state may be, as you say, an artefact of the more recent restore mechanism.

Thanks again for the reports. Can’t look into these issues just yet as am deep in some other stuff but we now have these reports which is great. Keep us informed of any progress and do take a look at that services.py file if you suspect stuff originates at that level.