Leon - the thread was about logwatch not logrotate.
On Saturday, 27 July 2019 04:14:04 UTC+3, Leon Shaner wrote:
>
> The Linux logrotate always works for anything I need. It's very flexible.
> I have an example on my weewx clone on GitHub in the watchdog util branch:
>
>
The Linux logrotate always works for anything I need. It's very flexible. I
have an example on my weewx clone on GitHub in the watchdog util branch:
https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPhone)
> On Jul 25,
On Friday, July 26, 2019 at 12:35:34 PM UTC-7, gjr80 wrote:
>
> The WeeWX installer does not ‘install’ the WeeWX logwatch files, rather
> the user must install them separately as per the wiki. The suggested
> approach is to create symlinks (in the relevant logwatch directories) to
> the
I’m sorry but I don’t understand the confusion here. WeeWX ships with 3
logwatch files; 2 config files and a script. The script is what analyses the
WeeWX log and produces the WeeWX logwatch report. The WeeWX installer does not
‘install’ the WeeWX logwatch files, rather the user must install
On Friday, July 26, 2019 at 10:01:47 AM UTC-7, Andrew Milner wrote:
>
> because logwatch is updated as weewx is updated if messages are altered -
> so if weewx provides an updated version the stashed away copy with the
> customisation becomes unusable basically.
>
>
Again - confused here.
because logwatch is updated as weewx is updated if messages are altered -
so if weewx provides an updated version the stashed away copy with the
customisation becomes unusable basically.
On Friday, 26 July 2019 17:52:02 UTC+3, vince wrote:
>
> On Thursday, July 25, 2019 at 11:49:39 AM UTC-7,
On Thursday, July 25, 2019 at 11:49:39 AM UTC-7, gjr80 wrote:
>
> The current top to bottom ‘if..elif..else’ structure does not lend itself
> to being easily extended in a manner that survives upgrades etc.
>
>
>
Agree - if you keep the file in weewx's directory namespace that is.
Doesn't
Hope the tuit surfaces soon!!! You summarised the issue perfectly.
On Thursday, 25 July 2019 21:49:39 UTC+3, gjr80 wrote:
>
> The logwatch script needs to be modularised so that users can easily
> extend the basic logwatch script functionality to cater for extensions and
> other
The logwatch script needs to be modularised so that users can easily extend the
basic logwatch script functionality to cater for extensions and other
customisations the user may have installed. The current top to bottom
‘if..elif..else’ structure does not lend itself to being easily extended in
On Thursday, July 25, 2019 at 6:10:20 AM UTC-7, Andrew Milner wrote:
>
> Just a bump any other suggestions/ideas or is it possible for other
> wiki based drivers and extensions to be included in the default weewx
> logwatch ignore list somehow?? maybe some form of customisation file which
Just a bump any other suggestions/ideas or is it possible for other
wiki based drivers and extensions to be included in the default weewx
logwatch ignore list somehow?? maybe some form of customisation file which
could be actioned/included - but how??
On Monday, 22 July 2019 12:31:13
I think I was confusing logwatch and logcheck; logcheck has directories
for various categories of messages including "ignore" of which I make
much use, while logwatch has scripts it runs for each service, which
means it can do rather more with the messages, but makes it a bit less
easily
that was my problem Rick - having to edit the weewx logwatch script to not
include the weewx extensions - raw, historygenerator and for some reason
ftpgenerator (not sure where that one came from anyway!!), so that my daily
weewx logwatch file from the weewx standard package is not filled with
On Mon 22 Jul Andrew Milner wrote:
> Is there a better way of handling this??
I don't edit logwatch filters that come with packages unless absolutely
necessary, but put my own additional filters into a different file in
the appropriate directory (typically with a name prefixed with local- to
14 matches
Mail list logo
