CentOS-6 Logwatch 7.3.6 Behaviour
After some experimenting I have observed that overriding settings from
/usr/share/logwatch/default.conf/logwatch.conf in
/etc/logwatch/conf/logwatch.conf does not produce consistent results.
For example, if I replace the default detail configuration in etc/logwatch/conf/logwatch.conf with:
Detail = High
It does indeed change the level of detail from the default Low set in
/usr/share/logwatch/default.conf/logwatch.conf.
However, if I comment out the line:
#Service = “-zz-sys” # Prevents execution of zz-sys service
in the overridden file then the fact that this line remains in the default.conf version means that the sservice cannot be enabled to run by default without editing
/usr/share/logwatch/default.conf/logwatch.conf. Of course doing that means that any update clobbers the local changes.
I am not sure if this a bug or a design feature but it seems to me that on should be able to override all of the default settings for services.
The only way around this seems to be to specify ‘–service All’ on the command line. But then the service entries in logwatch.conf seem to be ignored entirely so that one must also specify the service exclusions on the command line.
I also ran across a rather bizarre ‘feature’ with the ‘DisplayOrder’
setting. Evidently, if one gives the same DisplayOrder value to two or more services (say zz-sys which has DisplayOrder = 0.4 and zz-runtime which uses the default value of 0.5 otherwise) then only the last service (ordered alphabetically) is reported. No errors are logged or conflict notices are given either. The other service reports just ‘disappear’. However, one can explicitly assign multiple services a DisplayOrder value of 0.5 and all are reported nonetheless, in alphabetic order, along with the other services which simply take the implicit default value.
2 thoughts on - CentOS-6 Logwatch 7.3.6 Behaviour
In article, James B. Byrne wrote:
Can you just add it back in /etc/logwatch/conf/logwatch.conf with:
Service = “zz-sys”
I haven’t tried it, but it looks like Service lines are cumulative.
Cheers Tony
in the overridden file then the fact that this line remains in the default.conf version means that the sservice cannot be enabled to run Service = “zz-sys”
/usr/sbin/logwatch –range ‘today’ –mailto support@harte-lyne.ca
–service zz-runtime –service All Wrong configuration entry for “Service”, if “All” selected, only “-”
items are allowed
As shown above, if you pass ‘–service All’ then any later ‘–service X’ option must be prefaced with a ‘-‘ (‘–service -X’). In other words, once All is selected then one can only remove selected services. In the config files this is the order used:
# The ‘Service’ option expects either the name of a filter
# (in /usr/share/logwatch/scripts/services/*) or ‘All’.
# The default service(s) to report on. This should be left as All for
# most people. Service = All
# You can also disable certain services (when specifying all)
Service = “-zz-network” # Prevents execution of zz-network service, which
# prints useful network configuration info. Service = “-zz-sys” # Prevents execution of zz-sys service, which
# prints useful system configuration info. Service = “-eximstats” # Prevents execution of eximstats service, which
# is a wrapper for the eximstats program.
So, no, one cannot restore a service that is deleted from the run in default.conf by adding it back to the local config file.
I can understand what is happening here. The implementation of user config files is conceived as being additive to the default configuration. Anything not specified in
/etc/logwatch/conf/logwatch.conf is picked up from
/usr/share/logwatch/default.conf/logwatch.conf. Anything in
/usr/share/logwatch/default.conf/logwatch.conf is overridden by any similar entry in an earlier config.
This implies that the order of processing is:
/etc/logwatch/conf/logwatch.conf
/usr/share/logwatch/dist.conf
/usr/share/logwatch/default.conf/logwatch.conf
This seems to be something that needs to be fixed in the default.conf/logwatch.conf file.