Project

General

Profile

Bug #4531

RRD data restored in edge case where it shouldn't be, causing gap in graph

Added by Beat Siegenthaler about 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Low
Assignee:
-
Category:
Upgrade
Target version:
Start date:
03/18/2015
Due date:
% Done:

0%

Estimated time:
Affected Version:
All
Affected Architecture:
All

Description

Platform Alix/APU
You should trigger to write the RRD data to disk with the startup of the upgrade process.
Otherwise data is lost.

status_rrd_graph_img.php.png (50.7 KB) status_rrd_graph_img.php.png Beat Siegenthaler, 03/18/2015 02:45 AM

Associated revisions

Revision 05b7eef9 (diff)
Added by Chris Buechler about 4 years ago

Only restore rrd.tgz where platform is appropriate, or RAM disk being
used, otherwise you're restoring a probably old backup file. Ticket #4531

Revision 7c0c6355 (diff)
Added by Chris Buechler about 4 years ago

Only restore rrd.tgz where platform is appropriate, or RAM disk being
used, otherwise you're restoring a probably old backup file. Ticket #4531

History

#1 Updated by Chris Buechler about 4 years ago

Hm, the reboot process post-upgrade (same as the normal reboot process) saves the RRD data, which worked during release testing and every production/test system I've upgraded. I just checked a reboot from Diag>Reboot again, also fine there.

Did the system reboot normally on its own post-upgrade? Does your system normally save RRD data no problem cross-reboot? Normal reboot, not pulling the power plug. Pulling the plug will lose up until your last auto-save of RRD data (1-24 hours ago depending on config).

#2 Updated by Beat Siegenthaler about 4 years ago

indeed, i tried a reboot and it is the same problem. RRD save process is not invoked.

#3 Updated by Beat Siegenthaler about 4 years ago

Did some investigation:

rc.shutdown does not match condition for my system.

PLATFORM cat /etc/platform
pfSense

USE_MFS_TMPVAR /usr/bin/grep -c use_mfs_tmpvar /cf/conf/config.xml
0

DISK_NAME /bin/df /var/db/rrd | /usr/bin/tail -1 | /usr/bin/awk '{print $1;}'
/dev/ad4s1a

DISK_TYPE usr/bin/basename /dev/ad4s1a | /usr/bin/cut -c1-2
ad

# If we are not on a full install, or if the full install wants RAM disks, or if the full install _was_ using RAM disks, but isn't for the next boot...
if [ "${PLATFORM}" != "pfSense" ] || [ ${USE_MFS_TMPVAR} -gt 0 ] || [ "${DISK_TYPE}" = "md" ]; then
/etc/rc.backup_rrd.sh
/etc/rc.backup_dhcpleases.sh
fi

mount
/dev/ad4s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/md0 on /var/run (ufs, local)
devfs on /var/dhcpd/dev (devfs, local)

Hardware: pcEngines APU

CPU: AMD G-T40E Processor (1000.02-MHz K8-class CPU)
Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
Features2=0x802209<SSE3,MON,SSSE3,CX16,POPCNT>
AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
AMD Features2=0x35ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,IBS,SKINIT,WDT>
TSC: P-state invariant, performance statistics

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <SB mSATA SSD S9FM01.8> ATA-10 SATA 3.x device
ada0: Serial Number DDDF074704EE00608816
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 14318MB (29323728 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4

#4 Updated by Chris Buechler about 4 years ago

Beat Siegenthaler wrote:

mount
/dev/ad4s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/md0 on /var/run (ufs, local)
devfs on /var/dhcpd/dev (devfs, local)

That indicates you're running a normal full install, where it writes that data to / and not a RAM disk. With those as a RAM disk you'd see something like:

/dev/md0 on /tmp (ufs, local)
/dev/md1 on /var (ufs, local)

also correlates with the output shown.

Though now I see what's happening - if rrd.tgz exists, which it will since you have backups of it enabled, it gets extracted and restored upon boot. Since you're not in a situation where it's necessary (or really even useful) to backup the RRD data, that backup is skipped during shutdown. But the cron backup is enabled, so it restores during boot.

#5 Updated by Chris Buechler about 4 years ago

  • Status changed from New to Confirmed

#6 Updated by Chris Buechler about 4 years ago

  • Subject changed from RRD data lost from midnight with every upgrade to RRD data restored in edge case where it shouldn't be, causing gap in graph
  • Status changed from Confirmed to Resolved
  • Target version set to 2.2.2

fixed, that restore is skipped now in this specific circumstance since it's unnecessary.

#7 Updated by Chris Buechler about 4 years ago

  • Affected Version changed from 2.2.1 to All

Also available in: Atom PDF