Bug #8288: Many WARN messages after upgrade about JSON deserialisation error - Rudder - Issue Tracker

Actions

Copy link

Bug #8288

closed

Many WARN messages after upgrade about JSON deserialisation error

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

Status:

Released

Priority:

N/A

Assignee:

Vincent MEMBRÉ

Category:

Web - Config management

Target version:

2.11.22

Pull Request:

https://github.com/Normation/rudder/p...

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

Copy link

Updated by Jonathan CLARKE over 8 years ago

File warn-logs warn-logs added

Forgot the attachment

Actions

Copy link

Updated by François ARMAND over 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

Copy link