Keep in mind there is a fcron for old RRDs (over 1 year old):

# Cleanup the collectd RRD (graphs)
%weekly * * /bin/find /var/log/rrd -mtime +365 -type f -name '*.rrd' -delete -o -type d -empty -delete


On Feb 10, 2024, at 7:14 AM, Adolf Belka <adolf.belka@ipfire.org> wrote:

Hi Michael,

Sorry for delay in feedback.

I tried out the drop-hostile changes with both an update from CU182 to CU184 and a fresh install of CU184 and had an error message showing with the graph in both cases.

When I did the update from CU182 to CU184 the error message

/var/log/rrd/collectd/localhost/iptables-filter-HOSTILE_DROP_IN/ipt_bytes-DROP_HOSTILE.rrd

was not present.

See the screenshot attachment.

Checking the directories there was only the iptables-filter-HOSTILE_DROP directory and not the iptables-filter-HOSTILE_DROP_IN or iptables-filter-HOSTILE_DROP_OUT directories.

Maybe something needs to be done in the update.sh script to create the new directories. I am not sure what though.


When I did a fresh install from CU184 it was the other way round.

/var/log/rrd/collectd/localhost/iptables-filter-HOSTILE_DROP/ipt_bytes-DROP_HOSTILE.rrd

was not present.

Checking the directories there were the iptables-filter-HOSTILE_DROP_IN and iptables-filter-HOSTILE_DROP_OUT directories but not the iptables-filter-HOSTILE_DROP directory.

For a fresh install then there will be no history with the old naming so here I would think we need to create the old directory name as standard for everyone but it will just not have any data. If the user does a restore of an old backup then that HOSTILE_DROP data would become available.


On the fresh install of CU148 I did a restore of a backup from CU182 and then the graph worked as all three directories then were present.


Regards,

Adolf.
<firewall hits graph core update.png>