Project

General

Profile

Actions

Bug #4531

closed

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

Added by Beat Siegenthaler over 6 years ago. Updated over 6 years ago.

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

0%

Estimated time:
Plus Target Version:
Release Notes:
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.


Files

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

Updated by Chris Buechler over 6 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).

Actions #2

Updated by Beat Siegenthaler over 6 years ago

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

Actions #3

Updated by Beat Siegenthaler over 6 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

Actions #4

Updated by Chris Buechler over 6 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.

Actions #5

Updated by Chris Buechler over 6 years ago

  • Status changed from New to Confirmed
Actions #6

Updated by Chris Buechler over 6 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.

Actions #7

Updated by Chris Buechler over 6 years ago

  • Affected Version changed from 2.2.1 to All
Actions

Also available in: Atom PDF