Project

General

Profile

Actions

Bug #8208

closed

cronManagement 3.0 conflicts with bundle check_cron_daemon

Added by Janos Mattyasovszky over 8 years ago. Updated over 5 years ago.

Status:
Released
Priority:
N/A
Category:
Techniques
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
0
Name check:
Fix check:
Regression:

Description

Hi Folks,

Another day in Paradise...

Within the bundle check_cron_daemon in the file common/1.0/cron_setup.cf, there is this part of code:

57 #######################################################
58 # Check if the cron daemon is running
59 # This only works with unix flavoured systems too
60
61 bundle agent check_cron_daemon
62 {
...
82     # Fake success result, since we don't actually call service_restart unless it's needed
83     pass2.!(android|windows|aix).!restart_crond::
84       "any" usebundle => _classes_success("service_restart_${service_name}");

Unfortunately this happens in pass2, but this also makes cronManagement in version 3.0 go wild:

Unexpected reports' Message:

The cron process has been restarted
The cron process is running. Skipping...

The code for that is as follows:

110     pass3.!cron_restart::
111       "any" usebundle => rudder_common_report("cronConfiguration", "result_success", "${cron_uuid[${cron_index}]}", "Cron process", "None", "The cron process is running. Skipping...");
112
113     pass3.(service_restart_cron_ok|service_restart_crond_ok)::
114       "any" usebundle => rudder_common_report("cronConfiguration", "result_repaired", "${cron_uuid[${cron_index}]}", "Cron process", "None", "The cron process has been restarted");

And the code where the cron daemon is tested additionally:

127   processes:
128       "cron" 
129         process_select => cron_bin,
130         restart_class => "cron_restart";

Since the cron daemon is running, the cron_restart class in cronConfiguration.cf:*L130* is newer set, by this the report at cronConfiguration.cf:*L111* is reported correctly, however, since you fake the restart in cron_setup.cf:*L84*, the report in cronConfiguration.cf:*L113* is also reported badly.

It would probably help if it would also include the cron_restart class with the same scope, like this:

diff --git a/techniques/systemSettings/systemManagement/cronManagement/3.0/cronConfiguration.st b/techniques/systemSettings/systemManagement/cronManagement/3.0/cronConfiguration.st
index 8643d11..276532d 100644
--- a/techniques/systemSettings/systemManagement/cronManagement/3.0/cronConfiguration.st
+++ b/techniques/systemSettings/systemManagement/cronManagement/3.0/cronConfiguration.st
@@ -110,10 +110,10 @@ bundle agent check_cron_configuration
     pass3.!cron_restart::
       "any" usebundle => rudder_common_report("cronConfiguration", "result_success", "${cron_uuid[${cron_index}]}", "Cron process", "None", "The cron process is running. Skipping...");

-    pass3.(service_restart_cron_ok|service_restart_crond_ok)::
+    pass3.cron_restart.(service_restart_cron_ok|service_restart_crond_ok)::
       "any" usebundle => rudder_common_report("cronConfiguration", "result_repaired", "${cron_uuid[${cron_index}]}", "Cron process", "None", "The cron process has been restarted");

-    pass3.(service_restart_cron_not_ok|service_restart_crond_not_ok)::
+    pass3.cron_restart.(service_restart_cron_not_ok|service_restart_crond_not_ok)::
       "any" usebundle => rudder_common_report("cronConfiguration", "result_success", "${cron_uuid[${cron_index}]}", "Cron process", "None", "Could not restart the cron process!");

     pass3.(!windows.cron_absent)::

This fixed the issue about the double reporting.

I have found this is 3.0.13, but it's the same on master, so it should be present anywhere:
https://github.com/Normation/rudder-techniques/blob/master/techniques/systemSettings/systemManagement/cronManagement/3.0/cronConfiguration.st#L113
https://github.com/Normation/rudder-techniques/blob/master/techniques/system/common/1.0/cron_setup.st#L95

Actions

Also available in: Atom PDF