From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id A9D071FF16B for ; Thu, 14 Nov 2024 14:30:28 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 85A2630CD8; Thu, 14 Nov 2024 14:30:30 +0100 (CET) From: Thomas Lamprecht To: pbs-devel@lists.proxmox.com Date: Thu, 14 Nov 2024 14:29:50 +0100 Message-Id: <20241114132950.3536172-2-t.lamprecht@proxmox.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241114132950.3536172-1-t.lamprecht@proxmox.com> References: <20241114132950.3536172-1-t.lamprecht@proxmox.com> MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.047 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [rrd.rs] Subject: [pbs-devel] [PATCH 2/2] rrd: clamp future last_update time on load X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" We had already cases reported about systems where the BIOS had a time rather far in the future and thus anything that requires some time ordering might fail if it was initialised before an NTP system managed to sync the clock again. RRD updates are one such things, so as stop-gap just clam the last_update time on load. Signed-off-by: Thomas Lamprecht --- it might be nicer to clamp when saving the file, as that also has a higher chance to a NTP client having run and thus avoiding an error in the other direction, i.e., when the system is booted with time in the past. So feell free to take this over and rework for that case, just sending it out as I had a prototype around for some recent debug session on my machine. proxmox-rrd/src/rrd.rs | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/proxmox-rrd/src/rrd.rs b/proxmox-rrd/src/rrd.rs index 4bf4f01b..73a0ebd4 100644 --- a/proxmox-rrd/src/rrd.rs +++ b/proxmox-rrd/src/rrd.rs @@ -378,6 +378,11 @@ impl Database { if rrd.source.last_update < 0.0 { bail!("rrd file has negative last_update time"); + } else if rrd.source.last_update > proxmox_time::epoch_f64() { + let mut rrd = rrd; + log::error!("rrd file has last_update time from the future, clamping to now!"); + rrd.source.last_update = proxmox_time::epoch_f64(); + return Ok(rrd); } Ok(rrd) -- 2.39.5 _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel