fix(apache.service.running): prevent recursive requisite

[alxwr]

PR progress checklist (to be filled in by reviewers)

• Changes to documentation are appropriate (or tick if not required)
• Changes to tests are appropriate (or tick if not required)
• Reviews completed

---

What type of PR is this?

Primary type

• [build] Changes related to the build system
• [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
• [ci] Changes to the continuous integration configuration
• [feat] A new feature
• [fix] A bug fix
• [perf] A code change that improves performance
• [refactor] A code change that neither fixes a bug nor adds a feature
• [revert] A change used to revert a previous commit
• [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

• [docs] Documentation changes
• [test] Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.

Related issues and/or pull requests

–

Describe the changes you're proposing

I made this error go away: :-)

% salt --state-output=changes --state-verbose=False 'host.test' state.apply apache.config.file test=True
host.test:
----------
          ID: apache-service-running
    Function: service.running
        Name: apache2
      Result: False
     Comment: Recursive requisite found
     Changes:
[...]
----------
          ID: apache-service-running-restart
    Function: module.wait
        Name: service.restart
      Result: False
     Comment: Recursive requisite found
     Changes:   
----------
          ID: apache-service-running-reload
    Function: module.wait
        Name: service.reload
      Result: False
     Comment: Recursive requisite found
     Changes:

Pillar / config required to test the proposed changes

–

Debug log showing how the proposed changes work

% salt --state-output=changes --state-verbose=False 'host.test' state.apply apache.config.file test=True
host.test:
----------
          ID: apache-service-running
    Function: service.running
        Name: apache2
      Result: None
     Comment: Service apache2 is set to start  The state would be retried every 10 seconds (with a splay of up to 10 seconds) a maximum of 2 times or until a result of True is returned
     Started: 21:51:08.152014
    Duration: 12.319 ms
     Changes:   
----------
          ID: apache-service-running
    Function: cmd.run
        Name: journalctl -xe -u apache2 || tail -20 /var/log/messages || true
      Result: None
     Comment: Command "journalctl -xe -u apache2 || tail -20 /var/log/messages || true" would have been executed
     Started: 21:51:08.164573
    Duration: 0.464 ms
     Changes:   
              ----------
              cmd:
                  journalctl -xe -u apache2 || tail -20 /var/log/messages || true
----------
          ID: apache-service-running
    Function: cmd.run
        Name: (service apache2 restart && service apache2 status) || true
      Result: None
     Comment: Command "(service apache2 restart && service apache2 status) || true" would have been executed
     Started: 21:51:08.165158
    Duration: 0.414 ms
     Changes:   
              ----------
              cmd:
                  (service apache2 restart && service apache2 status) || true
----------
          ID: apache-service-running
    Function: cmd.run
        Name: cat /etc/apache2/apache2.conf
      Result: None
     Comment: Command "cat /etc/apache2/apache2.conf" would have been executed
     Started: 21:51:08.165693
    Duration: 0.417 ms
     Changes:   
              ----------
              cmd:
                  cat /etc/apache2/apache2.conf

Summary for host.test
-------------
Succeeded: 20 (unchanged=4, changed=3)
Failed:     0
-------------
Total states run:     20
Total run time:  110.024 ms

Documentation checklist

• Updated the README (e.g. Available states).
• Updated pillar.example.

Testing checklist

• Included in Kitchen (i.e. under state_top).
• Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
• Updated the relevant test pillar.

Additional context

[MartinZbozien]

Had this problem and these changes actually made it work properly.

[danny-smit]

Had the problem as well, this fixed it mostly. I only had to add the following change to remove the "Recursive requisite found" message for the configure modules:

diff --git a/formulas/apache/config/modules/install.sls b/formulas/apache/config/modules/install.sls
index 5bab8295..c7f4fecf 100644
--- a/formulas/apache/config/modules/install.sls
+++ b/formulas/apache/config/modules/install.sls
@@ -40,8 +40,6 @@ apache-config-modules-{{ module }}-enable:
 
         {%- endif %}
     - order: 225
-    - require:
-      - sls: {{ sls_config_file }}
     - watch_in:
       - module: apache-service-running-restart
     - require_in:

[danny-smit]

Small update to my previous comment.

The state in apache/config/modules/install.sls contains a hard order: 225, which would order it before all other states without an order key. This can give problems on new installed machines. Instead, the following change should fix both the "Recursive requisite" and the ordering issue:

diff --git a/apache/config/modules/install.sls b/apache/config/modules/install.sls
index 9cc5273..b85c80c 100644
--- a/apache/config/modules/install.sls
+++ b/apache/config/modules/install.sls
@@ -41,7 +41,7 @@ apache-config-modules-{{ module }}-enable:
         {%- endif %}
     - order: 225
     - require:
-      - sls: {{ sls_config_file }}
+      - file: apache-config-file-directory-moddir
     - watch_in:
       - module: apache-service-running-restart
     - require_in:

[dehnert]

danny-smit's April 18 comment did not on its own fix this for me.

The patch here plus:

diff --git a/apache/config/file.sls b/apache/config/file.sls
index 9cc5c93..9db036a 100644
--- a/apache/config/file.sls
+++ b/apache/config/file.sls
@@ -97,6 +97,8 @@ apache-config-file-managed:
       - sls: {{ sls_package_install }}
     - context:
         apache: {{ apache | json }}
+    - watch_in:
+      - service: apache-service-running
 
   {%- if grains.os_family in ('Debian', 'FreeBSD') %}
 
diff --git a/apache/config/modules/install.sls b/apache/config/modules/install.sls
index 9cc5273..b85c80c 100644
--- a/apache/config/modules/install.sls
+++ b/apache/config/modules/install.sls
@@ -41,7 +41,7 @@ apache-config-modules-{{ module }}-enable:
         {%- endif %}
     - order: 225
     - require:
-      - sls: {{ sls_config_file }}
+      - file: apache-config-file-directory-moddir
     - watch_in:
       - module: apache-service-running-restart
     - require_in:

did fix it. (I didn't try it with just the PR.)

Reading the PR:

• The changes to apache/config/file.sls are all just s/require_in/watch_in/`. AIUI the watch requisite implies the require requisite, so these are required either way, this just means that we restart Apache if they change.
  • Almost all the changes to file.sls are in file.directory states. I think if Apache previously crashed, service.running would rerun anyway, and it's unlikely that Apache would run but incorrectly without these directories, so I don't see why watch_in is needed. OTOH, it's probably harmless.
  • The other one is in OS-dependent config files (the diff looks like deleted lines, because the require_in is getting combined with the watch_in). This seems like an improvement, though it's hard to see how it would improve a circular dep.
  • (My change is to add a watch_in for the main config file. This seems like it would be pretty important to getting appropriate config-reloading behavior.)
• The removed requisites (which are presumably how you break a loop) are in apache/service/running.sls.
  • The three apache-service-running* states lose their watch (and usually require, which AIUI is redundant) on sls: {{ sls_config_file }}, which AFAICT is just the whole apache.config.file from earlier in the PR. Effectively, in combination with the earlier changes, I think this is replacing a broad dependency from the running states on the whole config file sls (in running.sls) with narrow dependencies from the running states to each of the config file states (in file.sls). My guess is that require: sls: whatever requires everything in that SLS, including the includes, and we include {{ sls_service_running}}, which would make a loop.
  • -reload and -running lose their watch/require entirely (there's no consistent watch_in for them), but they're after the service: apache-service-running. I can't find a definition of after, but my guess is this functionally means we need apache-service-running's prereqs, which is good enough. (Also these shouldn't run all that much.)

Anyway, I think the PR plus the patch above in this comment seems good and should get merged.