Project

General

Profile

Actions

Bug #8288

closed

Many WARN messages after upgrade about JSON deserialisation error

Added by Jonathan CLARKE almost 8 years ago. Updated almost 8 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Config management
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

See attached log file for all the messages.

A bit of background: I had a server running 3.1.4 that I upgraded to 3.2.2. Right after the upgrade finished, all these messages appeared in the webapp log.

Several issues to note:
1) These messages are pretty worrying, but seem to be only about invalid cache - maybe just silently ignore the cache if it's broken, and only log one human readable warning?
2) There are a bunch of errors that appear on lines all by themselves in the file, with no prefix, just like "stdout" style stuff

I'm not sure if this is related, but at the same time all my rules seemed to suddenly go into "Applying" compliance state.

Note: targeting to 3.2 because that's where I saw this but it could be older.


Files

warn-logs (265 KB) warn-logs Jonathan CLARKE, 2016-05-15 12:29
Actions #1

Updated by Jonathan CLARKE almost 8 years ago

Forgot the attachment

Actions #2

Updated by François ARMAND almost 8 years ago

Effectively, the message are not really grave. It's just an error when trying to deserialize the cache info. Typically, that can happen on a rudder update, if what is in the cache changed.
So we could but these message with a debug level.

The error lines should be removed, it's a badly handled stacktrace.

The "applying" is related: when we don't have the cache for a node configuration, we can't know if the node configuration changed, so we build a new one. As something in the cache structure change, it's very likelly that the configId won't be the same (because it's ~ based on the hash of the cache).

So, I propose to:
- change the debug level to info (so that it's displayed by default, and allow somehow to understand why nodes are on applying)
- clean up the error message to just display the node for which the cache are reseted.

Actions #3

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 3.2.3 to 3.2.4
Actions #4

Updated by François ARMAND almost 8 years ago

  • Target version changed from 3.2.4 to 2.11.22
Actions #5

Updated by François ARMAND almost 8 years ago

  • Status changed from New to In progress
Actions #6

Updated by François ARMAND almost 8 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Vincent MEMBRÉ
  • Pull Request set to https://github.com/Normation/rudder/pull/1112
Actions #7

Updated by François ARMAND almost 8 years ago

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

Updated by Vincent MEMBRÉ almost 8 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 2.11.22, 3.0.17, 3.1.11 and 3.2.4 which were released today.

Actions #9

Updated by François ARMAND over 7 years ago

  • Related to Bug #7336: Node stuck in "Applying" status added
Actions #10

Updated by François ARMAND over 7 years ago

  • Related to deleted (Bug #7336: Node stuck in "Applying" status)
Actions

Also available in: Atom PDF