# Error with suricata-update under RHEL10
**URL:** https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887
**Category:** Uncategorized
**Created:** [July 20, 2025, 9:57am UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887 "2025-07-20T09:57:38Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@clopmz](https://forum.suricata.io/u/clopmz)
#### Post date: [July 20, 2025, 9:57am UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/1 "2025-07-20T09:57:38Z")
Hi all,
suricata-update returns the following error under a RHEL10 host:
root@surisrv01:/etc/suricata# suricata-update -c /etc/suricata/update/update.yaml
20/7/2025 – 09:51:20 - – Loading /etc/suricata/update/update.yaml
20/7/2025 – 09:51:20 - – Using data-directory /var/lib/suricata.
20/7/2025 – 09:51:20 - – Using Suricata configuration /etc/suricata/suricata.yaml
20/7/2025 – 09:51:20 - – Using /opt/suricata/share/suricata/rules for Suricata provided rules.
20/7/2025 – 09:51:20 - – Found Suricata version 7.0.11 at /usr/local/bin/suricata.
20/7/2025 – 09:51:20 - – Loading /etc/suricata/update/disable.conf.
20/7/2025 – 09:51:20 - – Loading /etc/suricata/update/enable.conf.
20/7/2025 – 09:51:20 - – Loading /etc/suricata/update/modify.conf.
20/7/2025 – 09:51:20 - – Loading /etc/suricata/update/drop.conf.
20/7/2025 – 09:51:20 - – Loading /etc/suricata/suricata.yaml
20/7/2025 – 09:51:20 - – Disabling rules for protocol pgsql
20/7/2025 – 09:51:20 - – Disabling rules for protocol modbus
20/7/2025 – 09:51:20 - – Disabling rules for protocol dnp3
20/7/2025 – 09:51:20 - – Disabling rules for protocol enip
20/7/2025 – 09:51:20 - – No sources configured, will use Emerging Threats Open
20/7/2025 – 09:51:20 - – Fetching [https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz](https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz).
99% - 4980736/4985257
20/7/2025 – 09:51:51 - – Failed to copy file: The read operation timed out
I can download file [https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz](https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz) and uncompress it without problems in the same host. Where is the problem? How can I debug this?
---
### Author:  [@ish](https://forum.suricata.io/u/ish)
#### Post date: [July 20, 2025, 3:57pm UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/2 "2025-07-20T15:57:29Z")
On the same host, same user, same shell environment can you `curl -OL https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz`? Typically if that works, Suricata-Update should work as well.
Usually when I see the download failing at 99% there is some proxy, or WAF that thinks the rules are malware and dropping the last packets which can result in what you are seeing.
---
### Author:  [@clopmz](https://forum.suricata.io/u/clopmz)
#### Post date: [July 21, 2025, 9:12am UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/3 "2025-07-21T09:12:26Z")
Thanks @ish . Command curl works without problems … Theres is no WAF or firewall or another type of device disrupting https comms between suricata sensor and Internet … In fact, I can update RHEL without problems but suricata-update fails …
Is it possible to debug? Or maybe do I need to install addiitonal python package under RHEL? Actually the following packages are installed:
python3-3.12.9-2.el10\_0.2.x86\_64
python3-attrs-23.2.0-7.el10.noarch
python3-audit-4.0.3-1.el10.x86\_64
python3-charset-normalizer-3.3.2-7.el10.noarch
python3-cloud-what-1.30.6.1-1.el10\_0.x86\_64
python3-dasbus-1.7-8.el10.noarch
python3-dateutil-2.8.2-15.el10.noarch
python3-dbus-1.3.2-8.el10.x86\_64
python3-decorator-5.1.1-12.el10.noarch
python3-devel-3.12.9-2.el10\_0.2.x86\_64
python3-distro-1.9.0-5.el10.noarch
python3-dnf-4.20.0-12.el10\_0.noarch
python3-dnf-plugins-core-4.7.0-8.el10.noarch
python3-file-magic-5.45-7.el10.noarch
python3-gitdb-4.0.11-1.el10\_0.noarch
python3-GitPython-3.1.43-1.el10\_0.noarch
python3-gobject-base-3.46.0-7.el10.x86\_64
python3-gobject-base-noarch-3.46.0-7.el10.noarch
python3-hawkey-0.73.1-9.el10\_0.x86\_64
python3-idna-3.7-4.el10.noarch
python3-iniparse-0.5-10.el10.noarch
python3-inotify-0.9.6-36.el10.noarch
python3-jsonschema-4.19.1-7.el10.noarch
python3-jsonschema-specifications-2023.11.2-6.el10.noarch
python3-libcomps-0.1.21-3.el10.x86\_64
python3-libdnf-0.73.1-9.el10\_0.x86\_64
python3-librepo-1.18.0-5.el10\_0.x86\_64
python3-libs-3.12.9-2.el10\_0.2.x86\_64
python3-libselinux-3.8-2.el10\_0.x86\_64
python3-libsemanage-3.8.1-1.el10\_0.x86\_64
python3-libxml2-2.12.5-7.el10\_0.x86\_64
python3-linux-procfs-0.7.3-7.el10.noarch
python3-perf-6.12.0-55.21.1.el10\_0.x86\_64
python3-pip-23.3.2-7.el10.noarch
python3-pip-wheel-23.3.2-7.el10.noarch
python3-policycoreutils-3.8-1.el10.noarch
python3-pyudev-0.24.1-10.el10.noarch
python3-pyyaml-6.0.1-19.el10.x86\_64
python3-referencing-0.31.1-6.el10.noarch
python3-requests-2.32.3-2.el10.noarch
python3-rpds-py-0.17.1-6.el10.x86\_64
python3-rpm-4.19.1.1-12.el10.x86\_64
python3-semantic\_version-2.10.0-10.el10\_0.noarch
python3-setools-4.5.1-4.el10.x86\_64
python3-setuptools-69.0.3-12.el10\_0.noarch
python3-six-1.16.0-16.el10.noarch
python3-smmap-5.0.1-1.el10\_0.noarch
python3-subscription-manager-rhsm-1.30.6.1-1.el10\_0.x86\_64
python3-systemd-235-11.el10.x86\_64
python3-urllib3-1.26.19-2.el10.noarch
---
### Author:  [@ish](https://forum.suricata.io/u/ish)
#### Post date: [July 21, 2025, 3:35pm UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/4 "2025-07-21T15:35:56Z")
Unfortunately there isn’t much options for debugging (short of downloading the code and adding some print’s). This is a simple loop that reads 8k from the network at a time, and there error suggest its just not getting the end of the file. One thought is that this might happen if its failing to write the temporary file for any reason, but unlikely given the error message.
You could try the `curl -o /tmp/rules.tar.gz -L https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz` to rule out issues.
I have just tested on RHEL 10 to make sure this isn’t some repeatable issue on RHEL10.
---
### Author:  [@clopmz](https://forum.suricata.io/u/clopmz)
#### Post date: [July 27, 2025, 9:45am UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/5 "2025-07-27T09:45:30Z")
Good morning @ish
I have done some tests. I have installed a new host with Debian 13 this time, directly connected to Internet (no fws, no proxys, etc) and problem is the same: suricata-update returns “The read operation timed out” … with et and stamus open rules.
Using curl to donwload both sets of rules work ok … maybe, is it a bug with suricata-update?
---
### Author:  [@ish](https://forum.suricata.io/u/ish)
#### Post date: [July 27, 2025, 4:25pm UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/6 "2025-07-27T16:25:36Z")
> [@clopmz](#):
>
> 0/7/2025 – 09:51:20 - – Fetching [https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz](https://rules.emergingthreats.net/open/suricata-7.0.11/emerging.rules.tar.gz).
> 99% - 4980736/4985257
> 20/7/2025 – 09:51:51 - – Failed to copy file: The read operation timed out
Something to check is the behavior of the progress bar? Does it very slowly get to 99%? Or does it get to 99% quickly, then stall for about 30 seconds before the timeout?
If it gets to 99% very fast, then stalls, it suggests it’s something outside of Suricata-Update’s control, its waiting for the file to complete, but it never does.
You could try tweaking the timeout, find the file `suricata/update/net.py`, go to line `146`:
```auto
remote = opener.open(url, timeout=30)
```
and change that to something higher (120). However, its already well suited for very slow connections, as its a timeout per read call, not for the whole download.
---
### Author:  [@clopmz](https://forum.suricata.io/u/clopmz)
#### Post date: [July 29, 2025, 6:35am UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/7 "2025-07-29T06:35:40Z")
Hi @ish ,
The behaviour is exactly this: suricata-update gets to 99% quickly and then stall for 30 seconds and displays the timeout.
But I have done another test. I have another host with Suricata 7.0.11 under a FreeBSD 14 hosts deployed in the same network as Debian 13 and RHEL10 and the result is that suricata-update works without any problems on FreeBSD.
At this point, all that remains is for me to point to Python.
RHEL10: use python3.12 and suricata-update does not work.
Debian13: use python3.13 and suricata-update does not work.
FreeBSD14: use python3.11 and suricata-update works.
Could it be a problem with the Python stack?
---
### Author:  [@clopmz](https://forum.suricata.io/u/clopmz)
#### Post date: [July 29, 2025, 6:39am UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/8 "2025-07-29T06:39:32Z")
Sorry, I have changed timeout option in net.py file and result is the same.
---
### Author:  [@ish](https://forum.suricata.io/u/ish)
#### Post date: [July 29, 2025, 9:25pm UTC](https://forum.suricata.io/t/error-with-suricata-update-under-rhel10/5887/9 "2025-07-29T21:25:48Z")
I’ve added AlmaLinux 10 build to our CI which does a Suricata-Update with the `et/open` rules, and it does appear to pass:
>
>
> Based on the current AlmaLinux 9 build, with plugin tests, etc.
This matches my local testing that all passes:
- AlmaLinux 10, Python 3.12.9: OK
- RHEL 10, Python 3.12.9: OK
- Fedora 42, Python 3.13.5: OK
While we don’t host the `et/open` ruleset, we do host the index and I see many users fetching the index with Python 3.13, however not many from Debian 13 or RHEL10 yet, but typically we hear about critical problems pretty quick.
Are you able to test with something more common? Ubuntu 24.04 or AlmaLinux 9 are probably the most frequently used.