Feature #1851
closedadd verbosity level description to the help command
Added by Peter Manev over 8 years ago. Updated about 5 years ago.
Description
In essence -
suricata -h
should have the extra verbosity added/described in the help menu so that it is clearer when used on the command line.
-v info -vv info + perf -vvv info + perf + config
The very same values:
info perf config
can be used to be configured in suricata.yaml:
- file: enabled: yes level: info
Updated by Andreas Herz over 8 years ago
- Assignee set to OISF Dev
- Target version set to TBD
Updated by Victor Julien almost 8 years ago
- Assignee changed from OISF Dev to Andreas Herz
- Target version changed from TBD to 70
Updated by Andreas Herz over 7 years ago
I added that for the manpage and help command (PR done) but with the config I'm not sure what we want to have. The log level setting in the config won't take affect at all unless I use at least "-v" but it will never log more then added with "-v[vv]", so adding "config" as log level in the setting won't change the logfile output unless I also use "-vvv". But if I use "perf" as log level in the config and use "-vvv" I don't see the Config ouput in the logfile but in the stdout from the terminal where I start suricata. Looks like it's not what you might expect as user. IMHO the config setting should always affect the log level of the logfile and be seperated from the "-v[vv]" argument for the stdout output. Suggestions?
Updated by Peter Manev over 7 years ago
How about if we take the approach of command line override - if it is specified on the command line - it should override the config setting - aka "-vvv" should result in max verbosity.
Updated by Andreas Herz over 7 years ago
The PR was https://github.com/inliniac/suricata/pull/2877 but looks like we still need to define some parts. I'm a bit confused (see my post above as well) how we want those different settings (config and commandline) and levels to work.
Updated by Andreas Herz over 6 years ago
- Status changed from Assigned to New
- Assignee changed from Andreas Herz to OISF Dev
- Target version changed from 70 to TBD
- Effort set to medium
- Difficulty set to low
We still need to discuss/decide this :)
Updated by Victor Julien about 6 years ago
- Assignee changed from OISF Dev to Anonymous
Updated by Shivani Bhardwaj over 5 years ago
Is this still relevant? Can I take this up?
Updated by Jason Ish over 5 years ago
It sounds like we have to define what make sense and what the behaviour should be, then make sure the code matches that.
I'd like to recommend that -v, or multiple -v's only increase the verbosity, but to fixed levels. But will never decrease the verbosity set in the configuration file. For example:
-v -> info
-vv -> perf
-vvv -> config
-vvvv -> debug
(hmm, of note, I think config should come before perf but thats another topic)
This should change the verbosity level for any enabled output, but will never decrease the verbosity level. For example, if I have the file output enabled with level set to config, -v or -vv will not reset it to info or perf. However, -vvvv will set it to debug.
So -v is not an increase of whatever the configured level is as suggested in a PR which can be confusing to document.
-h output:
-v[vvvv] : be more verbose (use multiple times to increase verbosity)
And in the manual we could do something like:
.. option:: -v Increase the verbosity of the Suricata application output by increasing the log level. - -v: INFO - -vv: PERF - -vvv: CONFIG - -vvvv: DEBUG (if enabled) This option will not make the log level less verbose than configured in your suricata.yaml.
Updated by Victor Julien over 5 years ago
I agree. Think this is a large code change? If possible it would be nice to get this into 5.0, but if it is too intrusive we can push it back.
Updated by Jason Ish over 5 years ago
- Status changed from New to Assigned
- Assignee changed from Community Ticket to Jason Ish
- Target version changed from TBD to 5.0.0
Victor Julien wrote:
I agree. Think this is a large code change? If possible it would be nice to get this into 5.0, but if it is too intrusive we can push it back.
I don't think its very large at all. I'm willing to give it a couple hours, then if I'm wrong, avoid spending too much time on it until after 5.0.
Updated by Jason Ish about 5 years ago
- Related to Bug #3210: Individual output log levels capped by the default log level added
Updated by Jason Ish about 5 years ago
- Status changed from Assigned to Closed