Bug #8155
closed
No answer with common / update
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
- Summary #####################################################################
success: 19
execution time: 2.79s
################################################################################_
Files
| update-report.png (35.2 KB) update-report.png | |||
| run1.log (4.19 KB) run1.log | |||
| run2.log (3.66 KB) run2.log | |||
| run2_verbose.log (548 KB) run2_verbose.log | |||
| run3.log (3.94 KB) run3.log | |||
| run3_verbose.log (557 KB) run3_verbose.log | |||
| update1 (7.26 KB) update1 | |||
| update2 (7.08 KB) update2 | |||
| update3 (6.91 KB) update3 |
Updated by Nicolas CHARLES over 8 years ago
- Translation missing: en.field_tag_list set to Sponsored
- Category set to System techniques
- Assignee set to Alexis Mousset
- Priority changed from N/A to 1 (highest)
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
Updated by Vincent MEMBRÉ over 8 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.
Updated by Alexandre Anriot over 8 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.
Updated by Vincent MEMBRÉ over 8 years ago
- File run1.log run1.log added
- File run2.log run2.log added
- File run2_verbose.log run2_verbose.log added
- File run3.log run3.log added
- File run3_verbose.log run3_verbose.log added
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
Updated by Nicolas CHARLES over 8 years ago
- Assignee changed from Alexis Mousset to Nicolas CHARLES
Updated by Alexandre Anriot about 8 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,
Updated by Joonas Harjumaki about 8 years ago
I would not close this ticket. I'm seeing this behaviour with rudder-agent 3.2.6 on Centos 6/Debian Wheezy.
Updated by Alexandre Anriot about 8 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.
Updated by Alexis Mousset about 8 years ago
- Assignee changed from Nicolas CHARLES to Alexis Mousset
Seen this on 4.0.0-rc5 too.
Updated by Alexis Mousset about 8 years ago
Added classes defined just after update (update1), during missing reports (update2), and when reporting is fixed (update3).
(thanks to dumpdatastate())
Updated by Alexis Mousset about 8 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 |
Updated by Alexis Mousset about 8 years ago
- Status changed from New to In progress
Updated by Alexis Mousset about 8 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
Updated by Alexis Mousset about 8 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.
Updated by Alexis Mousset about 8 years ago
- Status changed from Pending technical review to In progress
- Assignee changed from Benoît PECCATTE to Alexis Mousset
Updated by Alexis Mousset about 8 years ago
- Status changed from In progress to Pending technical review
- Assignee changed from Alexis Mousset to Benoît PECCATTE
Updated by Alexis Mousset about 8 years ago
- Status changed from Pending technical review to In progress
- Assignee changed from Benoît PECCATTE to Alexis Mousset
Updated by Alexis Mousset about 8 years ago
- Status changed from In progress to Pending technical review
- Assignee changed from Alexis Mousset to Benoît PECCATTE
Updated by Alexis Mousset about 8 years ago
- Pull Request changed from https://github.com/Normation/rudder-techniques/pull/1077 to https://github.com/Normation/rudder-techniques/pull/1078
Updated by Alexis Mousset about 8 years ago
- Status changed from Pending technical review to Pending release
- % Done changed from 0 to 100
Applied in changeset rudder-techniques|745191b2a64c9e2df4bc87f4a27b143da55f8353.
Updated by Vincent MEMBRÉ almost 8 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.
- 4.0.1: Announce Changelog
- 3.2.10: Announce Changelog
- Download: https://www.rudder-project.org/site/get-rudder/downloads/