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.

1. 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.

2. 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

3. 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

4. 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.

5. 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.

6. 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.

7. 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.