From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4dSb6D3fBlz30H4 for ; Fri, 12 Dec 2025 16:49:56 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4dSb684cgyz2xWj for ; Fri, 12 Dec 2025 16:49:52 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4dSb676NVhz2b9 for ; Fri, 12 Dec 2025 16:49:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1765558191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=CK2CaeXqxRPYJWQVfY9WK2iRuK5ZLlHyq09YtNJWtHM=; b=Jh3G5b1/RXkpZR9x1KYB5wRG7dVwjC2/0nfh17/iAcShmJdqDHuin6IHu2pnn/a2MwHb8M hsIwFtH7KEqUovlDNzuTIg0Td+1Ihor5R8bDreZC4nydKggJ7caUHwkkyjBCgsaw79g1M6 wT1XOkFa5WsMC41fzIJCRrZQUQrleUhz2lIXGxX+AlgbjjsP5c13IbSFeKZkSCl8CRMN4I jzqoMUD63af29KRId9Dhzfc0gkrVHtt5sd4bxYrbsoCq/dV+FsC497StbG5Z964/ad79zs pY8IDHsPvsNPNBw5y4fCX49GPt3TZ2DXVShkIPLTXxavjrCe50/22iDf6u/yXg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1765558191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=CK2CaeXqxRPYJWQVfY9WK2iRuK5ZLlHyq09YtNJWtHM=; b=BbcOWYmrtZ4AWPa2D7+2QSR57GCkpME2NKeF8wz4bNYV7O0uLdPLAhOkCCASASeH0KnfZ6 hTeFemt64NgovYAQ== Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Date: Fri, 12 Dec 2025 16:49:51 +0000 From: Adam Gibbons To: Development Subject: Large Suricata cache directory. Message-ID: <8ac70e7aa3d72cf2de5cda09a52f1cf6@ipfire.org> X-Sender: adam.gibbons@ipfire.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, As discussed on the forum https://community.ipfire.org/t/re-large-backupfile/15346 it appears that Suricata’s new cache optimisation feature is creating a large number of files under `/var/cache/suricata/sgh/`, which in some cases causes backup files to grow to 800+ MB. @Adolf has confirmed that this directory probably should not be included in backups, as it is automatically regenerated, and I believe he mentioned he is working on a patch to exclude it from the backup. However, in the meantime, this directory continues to grow over time. The upstream Suricata patches to automatically clean or maintain the cache have not yet been merged, although they may be soon: https://github.com/OISF/suricata/pull/13850 https://github.com/OISF/suricata/pull/14400 To me this represents a disk-space exhaustion risk on systems with limited storage. Perhaps we should consider disabling Suricata’s new cache optimisation feature until automatic cache cleanup/maintenance is available upstream and included. Thanks, Adam