Project

General

Profile

Actions

Bug #8155

closed

No answer with common / update

Added by Alexandre Anriot about 5 years ago. Updated over 4 years ago.

Status:
Released
Priority:
1
Category:
System techniques
Target version:
Severity:
User visibility:
Effort required:
Priority:
Tags:

Description

Hello,

As seen with Nicolas, we got a few times no answer on the update component of the common technique while executing the Linux agent on a Jessie system.

I have to mention that it has recovered during the next runs.

You will find a trace below.

Thanks.

_$ rudder agent run
Rudder agent 3.2.0-jessie0 (CFEngine Core 3.7.1)
Node uuid: XXXXXX
Start execution with config [YYYYYY]

Result Technique Component Key Message
success Common Security parameters The internal environment security is acceptable
success Common Red Button Red Button is not in effect, continuing as normal...
success Common Process checking There is an acceptable number of CFEngine processes running on the machine
success Common CRON Daemon Cron daemon status was correct
success Common Binaries update The CFengine binaries in /var/rudder/cfengine-community/bin are up to date
success Common Log system for reports Logging system for report centralization is already correctly configured
success Inventory inventory Next inventory scheduled between 00:00 and 06:00
success packageInstallation Debian/Ubuntu packages apache2 No action required for deb package apache2 with policy: add
success packageInstallation Debian/Ubuntu packages mysql-client No action required for deb package mysql-client with policy: add
success packageInstallation Debian/Ubuntu packages mysql-server No action required for deb package mysql-server with policy: add
success packageInstallation Debian/Ubuntu packages php7.0 No action required for deb package php7.0 with policy: add
success repoGpgKeyManagement Repository GPG Key Manag| ZZZZZZ The GPG Key is already imported
success aptPackageManagerSettings aptPackageManagerSettings APT settings were all already correct

  1. Summary #####################################################################
    success: 19
    execution time: 2.79s
    ################################################################################_

Files

update-report.png (35.2 KB) update-report.png Alexandre Anriot, 2016-04-06 18:17
run1.log (4.19 KB) run1.log Vincent MEMBRÉ, 2016-06-07 16:08
run2.log (3.66 KB) run2.log Vincent MEMBRÉ, 2016-06-07 16:09
run2_verbose.log (548 KB) run2_verbose.log Vincent MEMBRÉ, 2016-06-07 16:09
run3.log (3.94 KB) run3.log Vincent MEMBRÉ, 2016-06-07 16:09
run3_verbose.log (557 KB) run3_verbose.log Vincent MEMBRÉ, 2016-06-07 16:09
update1 (7.26 KB) update1 Alexis MOUSSET, 2016-10-28 16:17
update2 (7.08 KB) update2 Alexis MOUSSET, 2016-10-28 16:17
update3 (6.91 KB) update3 Alexis MOUSSET, 2016-10-28 16:17
Actions #1

Updated by Nicolas CHARLES about 5 years ago

  • Tags set to Sponsored
  • Category set to System techniques
  • Assignee set to Alexis MOUSSET
  • Priority changed from N/A to 1

Thank you Alexandre. Assigning to Alexis who would be the best to analyze it.
Happens at least in 3.2.1, but may happen in previous versions

Actions #2

Updated by Vincent MEMBRÉ almost 5 years ago

I may have reproduced that case:

First run, update the promises and we got a "repaired".
The second run after the update did not report on Update, leading to a missing report
The third run reports a success report.

Actions #3

Updated by Alexandre Anriot almost 5 years ago

Great !

Vincent MEMBRÉ wrote:

I may have reproduced that case:

First run, update the promises and we got a "repaired".
The second run after the update did not report on Update, leading to a missing report
The third run reports a success report.

Actions #4

Updated by Vincent MEMBRÉ almost 5 years ago

Here some logs from the 3 runs:

run1: Update repaired
run2: no Update
run3: Update success

I have verbose output for 2 and 3 in which you can see that in run2 there is no persistant classes for update set (and maybe explaining the no report ...)

To understand why their is no classes i need to run verbose failsafe but I already saw that if i run more failsafe manually it does not occur ... #boooooooring

Actions #5

Updated by Nicolas CHARLES almost 5 years ago

  • Assignee changed from Alexis MOUSSET to Nicolas CHARLES
Actions #6

Updated by Alexandre Anriot over 4 years ago

Hello,

I haven't seen this issue again for several weeks now.

I guess that you can close the ticket for now.

Cheers,

Actions #7

Updated by Joonas Harjumaki over 4 years ago

I would not close this ticket. I'm seeing this behaviour with rudder-agent 3.2.6 on Centos 6/Debian Wheezy.

Actions #8

Updated by Alexandre Anriot over 4 years ago

No problem, sorry.

Joonas Harjumaki wrote:

I would not close this ticket. I'm seeing this behaviour with rudder-agent 3.2.6 on Centos 6/Debian Wheezy.

Actions #9

Updated by Alexis MOUSSET over 4 years ago

  • Assignee changed from Nicolas CHARLES to Alexis MOUSSET

Seen this on 4.0.0-rc5 too.

Actions #10

Updated by Alexis MOUSSET over 4 years ago

Added classes defined just after update (update1), during missing reports (update2), and when reporting is fixed (update3).

(thanks to dumpdatastate())

Actions #11

Updated by Alexis MOUSSET over 4 years ago

update1 update2 update3
config
config_ok
rudder_ncf_common_updated
rudder_ncf_common_updated_ok rudder_ncf_common_updated_ok
rudder_ncf_hash_update_ok rudder_ncf_hash_update_ok rudder_ncf_hash_update_ok
rudder_ncf_hash_update_repaired
rudder_ncf_local_updated_ok rudder_ncf_local_updated_ok
rudder_promises_generated_tmp_file_kept rudder_promises_generated_tmp_file_kept rudder_promises_generated_tmp_file_kept
rudder_promises_generated_tmp_file_repaired rudder_promises_generated_tmp_file_repaired
rudder_tools_updated
rudder_tools_updated_kept rudder_tools_updated_kept rudder_tools_updated_kept
rudder_tools_updated_ok
rudder_tools_updated_repaired rudder_tools_updated_repaired
Actions #12

Updated by Alexis MOUSSET over 4 years ago

  • Target version set to 3.1.17
Actions #13

Updated by Alexis MOUSSET over 4 years ago

  • Status changed from New to In progress
Actions #14

Updated by Alexis MOUSSET over 4 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Alexis MOUSSET to Benoît PECCATTE
  • Pull Request set to https://github.com/Normation/rudder-techniques/pull/1077
Actions #15

Updated by Alexis MOUSSET over 4 years ago

  • Target version changed from 3.1.17 to 3.2.10

The problem comes from rudder_promises_generated_repaired which is defined during second run after update (as it is a temp file that is used for comparison. Removing it from the "!" classes fixes the issue.

The issue probably appeared in 3.2 when changing update mechanism.

Actions #16

Updated by Alexis MOUSSET over 4 years ago

  • Status changed from Pending technical review to In progress
  • Assignee changed from Benoît PECCATTE to Alexis MOUSSET
Actions #17

Updated by Alexis MOUSSET over 4 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Alexis MOUSSET to Benoît PECCATTE
Actions #18

Updated by Alexis MOUSSET over 4 years ago

  • Status changed from Pending technical review to In progress
  • Assignee changed from Benoît PECCATTE to Alexis MOUSSET
Actions #19

Updated by Alexis MOUSSET over 4 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Alexis MOUSSET to Benoît PECCATTE
Actions #20

Updated by Alexis MOUSSET over 4 years ago

  • Pull Request changed from https://github.com/Normation/rudder-techniques/pull/1077 to https://github.com/Normation/rudder-techniques/pull/1078
Actions #21

Updated by Alexis MOUSSET over 4 years ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100
Actions #22

Updated by Vincent MEMBRÉ over 4 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 4.0.1 and 3.2.10 which were released today.

Actions

Also available in: Atom PDF