Bug #1911
open
Commandline provided configuration values don't persist after initial startup
Added by Antti Tönkyrä about 8 years ago.
Updated over 2 years ago.
Description
When using --set key=value commandline arguments to set some configuration parameters on startup, it seems that those values are not carried across reloads.
What I'd expect would happen:
# suricata ... --set default-rule-path=/some/path
kill -USR2 suricata_pid
<suricata reloads normally, reading rules from /some/path>
What actually happens
# suricata ... --set default-rule-path=/some/path
kill -USR2 _suricata_pid
<suricata reloads normally, reading rules from default (compiled in) /etc/suricata/rules but due to wrong directory in regard of --set argument, the rule files aren't found -> operation continues with empty ruleset>
Related issues
1 (1 open — 0 closed)
- Assignee set to Jason Ish
- Target version set to TBD
Think the issue likely is related to the new namespace we load the new config into?
Something like that. --set has issues in how its used, and I think its how I mark certain configuration parameters as "final". So if you go and load a new config, and don't iterate through the old config looking for the "final" values, you'll lose them.
I've talked before about having to config trees. Once that contains values set on the command line, the other the values from the file. When looking something up it will look in the command line conf tree first, then fall back to the file. So if I file reload takes place, it shouldn't matter.
It comes with other issues like how to properly iterate the full config for a dump.
Jason did you dig into that deeper?
- Related to Feature #4782: config: add command to dump all active settings added
- Status changed from New to In Review
Also available in: Atom
PDF