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 #1

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?

Actions #2

Updated by Janos Mattyasovszky over 8 years ago

  • Status changed from New to Pending release
  • % Done changed from 0 to 100
Actions #3

Updated by Janos Mattyasovszky over 8 years ago

  • Assignee changed from Nicolas CHARLES to Benoît PECCATTE
Actions #4

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.

Actions #5

Updated by Alexis Mousset over 8 years ago

  • Status changed from Pending release to Released
Actions #6

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

  1. 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.

Actions #7

Updated by Alexis Mousset over 5 years ago

  • Target version set to 3.1.10
  • Priority set to 0
Actions

Also available in: Atom PDF