Project

General

Profile

Actions

Bug #8994

closed

Two RRDDATA Sections in Restored Config Breaks Unit

Added by Chris Linstruth over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Backup / Restore
Target version:
Start date:
10/02/2018
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4
Affected Architecture:

Description

Had a user present a configuration backup with two rrddata sections.

Looked like this:

<rrddata></rrddata>
<rrddata>
<rrddatafile>

The configuration uploaded but the config parser did not like it:

Fatal error: Uncaught Exception: XML error: RRDDATA at line 2179 cannot occur more than once in /etc/inc/xmlparse.inc:87 ...

Removing the empty rrddata section allowed the configuration to be uploaded and applied successfully.

It was an 18.0 (2.4.3_1) backup.


Related issues

Related to Bug #13132: Multiple ``<sshdata>`` or ``<rrddata>`` sections in ``config.xml`` lead to an XML parsing error during restoreResolvedJim Pingle

Actions
Actions #1

Updated by Paighton Bisconer over 5 years ago

I don't think this is limited to <rrddata>, any duplicate tag in the config will break imports, I've confirmed with <vlans> and <laggs> but I would think it applies to all duplicate sections.

Actions #2

Updated by Jim Pingle over 5 years ago

  • Target version set to 2.4.4-p1

The rrddata case is special because of the way the backup process injects the data into the config before serving the backup to the user. The others could only happen by manual duplication.

I pushed a fix to avoid the problem case on both backup and restore.

Actions #3

Updated by Jim Pingle over 5 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #4

Updated by Chris Linstruth over 5 years ago

Tested restoring the original problematic config.xml. It did restore successfully but there was no rrddata in the result after reboot.

Actions #5

Updated by Jim Pingle over 5 years ago

  • Status changed from Feedback to Resolved

Did you look far enough back in time on the graphs to see data from the date before the backup was taken?

I took a backup with RRD, edited in the bad blank tag, reset RRD so everything was blank, then restored. The RRD data from the backup was restored as expected. Looks good here. I had to set the time span on the graph to a week to see anything meaningful in the graphs after restore since that was the last obvious spike.

Actions #6

Updated by Chris Linstruth over 5 years ago

There was no rrd section in the resulting configuration at all.

Actions #7

Updated by Jim Pingle over 5 years ago

It should be removed by the restore as its last act, since the data is taken out of config.xml and converted back into the RRD data file format expected by rrdtool. Checking the graphs is the best way to reliably know if the restore succeeded.

Only the backup should contain <rrddata> tags, they should never been seen in a live config.

Actions #8

Updated by Jim Pingle over 1 year ago

  • Related to Bug #13132: Multiple ``<sshdata>`` or ``<rrddata>`` sections in ``config.xml`` lead to an XML parsing error during restore added
Actions

Also available in: Atom PDF