Bug #8208
closedcronManagement 3.0 conflicts with bundle check_cron_daemon
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
Updated by Janos Mattyasovszky over 8 years ago
- Assignee set to Nicolas CHARLES
- Pull Request set to https://github.com/Normation/rudder-techniques/pull/915
PR at https://github.com/Normation/rudder-techniques/pull/915
@ncharles: could you review that pls?
Updated by Janos Mattyasovszky over 8 years ago
- Status changed from New to Pending release
- % Done changed from 0 to 100
Applied in changeset rudder-techniques|76a19b70c173aa2ec3fe220955b3417b7a56bedc.
Updated by Janos Mattyasovszky over 8 years ago
- Assignee changed from Nicolas CHARLES to Benoît PECCATTE
Updated by Alexis Mousset over 8 years ago
This bug has been fixed in Rudder 3.1.10 and 3.2.3 which were released on 2016-06-01, but not announced.
- 3.1: Changelog
- 3.2: Changelog
- Download: https://www.rudder-project.org/site/get-rudder/downloads/
Updated by Alexis Mousset over 8 years ago
- Status changed from Pending release to Released
Updated by Florian Heigl over 8 years ago
Alexis,
I'm not sure if this is fixed :/
I'm getting the cron restart here:
@root@dhcp220:~# rudder agent run
Rudder agent 3.2.5-trusty0 (CFEngine Core 3.7.1)
Node uuid: c88982f4-7ed0-45a6-bcc8-1928b27d9a2d
Start execution with config [-2075847121]
Result Technique Component Key Message
repaired Common Update Rudder policy, tools or ncf instance were updated or CFEngine service restarted
repaired bacula_client_install_de| Service ensure running bacula-fd Ensure that service bacula-fd is running was repaired
repaired cronConfiguration Cron process The cron process has been restarted
repaired cronConfiguration Cron process The cron process has been restarted
- Summary #####################################################################
repaired: 4
execution time: 3.59s
################################################################################@
My Server is on 3.1.12.
Techniques are updated and commited.
I'm seeing it re-restarting the cron process with the 3.2.5 agent on Ubuntu and with 3.1.12 agent on CentOS.
Updated by Alexis Mousset over 5 years ago
- Target version set to 3.1.10
- Priority set to 0