Bug #8994
closed
Two RRDDATA Sections in Restored Config Breaks Unit
100%
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
Updated by Paighton Bisconer about 6 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.
Updated by Jim Pingle about 6 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.
Updated by Jim Pingle about 6 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 9386784480f27d6b04ebf013f691522130a7f013.
Updated by Chris Linstruth about 6 years ago
Tested restoring the original problematic config.xml. It did restore successfully but there was no rrddata in the result after reboot.
Updated by Jim Pingle about 6 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.
Updated by Chris Linstruth about 6 years ago
There was no rrd section in the resulting configuration at all.
Updated by Jim Pingle about 6 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.
Updated by Jim Pingle about 2 years ago
- Related to Bug #13132: Multiple ``<sshdata>`` or ``<rrddata>`` sections in ``config.xml`` lead to an XML parsing error during restore added