How to reload Suricata rules

Rule reloads let a running Suricata sensor pick up changed signatures without stopping packet inspection. They fit managed ruleset updates, local rule edits, and rule-variable changes when a full service restart would create an inspection gap.

Suricata's UNIX command socket lets suricatasc ask the running engine to load rule-related files from disk and swap in a new detection engine. The socket must belong to the same Suricata process that is inspecting traffic, so packaged services should use the default socket path unless unix-command.filename was customized.

A rule reload is for rule-related resources such as suricata.rules, classification.config, reference.config, threshold.config, datasets, and rule variables. Restart the service instead after changing capture interfaces, logging outputs, threading, run mode, or other non-rule configuration.

Steps to reload Suricata rules:

Confirm the command socket reaches the running Suricata process.
```
$ sudo suricatasc -c version
{"message":"8.0.3 RELEASE","return":"OK"}
```
If the service uses a custom socket, pass the socket path before -c, such as sudo suricatasc /run/suricata/custom.socket -c version.

Update the managed ruleset or save the rule file that changed.

$ sudo suricata-update
25/6/2026 -- 07:56:06 - <Info> -- Using Suricata configuration /etc/suricata/suricata.yaml
25/6/2026 -- 07:56:06 - <Info> -- No sources configured, will use Emerging Threats Open
##### snipped #####
25/6/2026 -- 07:56:13 - <Info> -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 66793; enabled: 50866; added: 66793; removed 0; modified: 0
25/6/2026 -- 07:56:13 - <Info> -- Testing with suricata -T.
25/6/2026 -- 07:56:19 - <Info> -- Done.

Use the same rule-update path that feeds the active rule-files list. A custom rule file must already be listed in suricata.yaml before a reload can load it.
Related: How to update Suricata rules

Test the changed configuration and ruleset before reloading the running engine.

$ sudo suricata -T -c /etc/suricata/suricata.yaml -v
Notice: suricata: This is Suricata version 8.0.3 RELEASE running in SYSTEM mode
Info: suricata: Running suricata under test mode
Info: detect: 1 rule files processed. 50866 rules successfully loaded, 0 rules failed, 0 rules skipped
Info: threshold-config: Threshold config parsed: 0 rule(s) found
Info: detect: 50871 signatures processed. 1285 are IP-only rules, 4505 are inspecting packet payload, 44845 inspect application layer, 110 are decoder event only
Notice: suricata: Configuration provided was successfully loaded. Exiting.

Do not reload after a failed test; fix the YAML, rule, threshold, classification, reference, or dataset error first.
Related: How to test Suricata configuration

Check the currently loaded ruleset stats from the running process.
```
$ sudo suricatasc -c ruleset-stats
{"message":[{"id":0,"rules_loaded":50866,"rules_failed":0,"rules_skipped":0}],"return":"OK"}
```
rules_loaded is the running engine's current view, not just the generated file on disk.
Reload the rules and wait for the reload to complete.
```
$ sudo suricatasc -c reload-rules
{"message":"done","return":"OK"}
```
reload-rules is the blocking form of ruleset-reload-rules. Use ruleset-reload-nonblocking only when automation should continue before the reload finishes.

Confirm that Suricata recorded a rule reload time.

$ sudo suricatasc -c ruleset-reload-time
{"message":[{"id":0,"last_reload":"2026-06-25T07:56:35.136589+0000"}],"return":"OK"}

The timestamp should be later than the rule file update or local rule edit.

Confirm that the reloaded ruleset has no failed rules.
```
$ sudo suricatasc -c ruleset-stats
{"message":[{"id":0,"rules_loaded":50866,"rules_failed":0,"rules_skipped":0}],"return":"OK"}
```
If rules_failed is greater than 0, run sudo suricatasc -c ruleset-failed-rules and inspect /var/log/suricata/suricata.log before relying on the new ruleset.