similar to: Processed: clarify things

Package: logcheck Version: 1.2.58.0 Severity: wishlist Tags: patch The attached patch is the diff from current svn trunk to my svn branch zugschlus200707. It introduces a new binary package logtail2 with a new binary logtail2 which enhances logtail substantially. logtail2 can process rotated logs internally, which makes the code inside logcheck and other programs that use logtail2 easier to

Hello, I'm having this error: Warning: If you are seeing this message, your log files may not have been checked! Details: Could not run logtail or save output Check temporary directory: /tmp/logcheck.EIX3jp declare -x HOME="/var/lib/logcheck" declare -x LANG="en_US" declare -x LANGUAGE="en_US:en_GB:en" declare -x LOGNAME="logcheck" declare -x

Hello! We have long running process and execute "cat /dev/null > logfile" to control logfile size. So it is normal case, when a log file is smaller. We would like to introduce new flag to disable the warning message. Please, accept the attached patch. --- /usr/sbin/logtail 2010-09-03 11:25:15.000000000 +0300 +++ logtail 2013-08-20 12:38:22.000000000 +0300 @@ -27,7 +27,7 @@ #

hello everyone, thanks to todd 1.2.21 is out :) every release getting better, i would like to get consensus on these "important" bugs: #252078 logtail: should depend on perl >= 5.8 sarge as any other modern linux distro use perl 5.8.x, it's even inside of its base. backports are under the peril of its author if no one voices up, i'll close that bug in the next days.

Package: logcheck Version: 1.2.47 Severity: wishlist I'm running logcheck with an extended set of regular expressions on a desktop system. The CPU load of this system is normally very low, around 3%-5%. When logcheck starts scanning the logs, the CPU usage increases to 100% for several minutes and working on the system becomes difficult. I would therefore be very happy about if a

hi before checking in that chown fix, i wanted you to take a look. tested on my workstation. basicaly the patch takes care that logtail saves the offset file with the correct permissions. when playing around lately with file tampering and those invoking logcheck as root. i got similar output to #253998 Alfie may point out that i should not invoke logcheck as root, but i better fix that before

Processing commands for control at bugs.debian.org: > # Automatically generated email from bts, devscripts version 2.9.20 > package logcheck logcheck-database logtail Ignoring bugs not assigned to: logcheck-database logtail logcheck > tags 354820 + pending Bug#354820: rules to filter out entries caused by ssh scanners Tags were: patch Tags added: pending > tags 355085 + pending

Package: logcheck Version: 1.2.26 Severity: wishlist Please add ignore for Spamassasin's "check" messages like: Aug 16 19:27:54 ns spamd[23853]: checking message <20040816150710.86ADA708A8 at smtp-out.hotpop.com> for nobody:65534. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.26.20040601 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL

Package: logcheck Version: 1.2.42 Severity: wishlist -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are some more messages that can be safely ignored: localhost kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core localhost kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for PocketPC PDA localhost kernel: drivers/usb/serial/ipaq.c: USB PocketPC PDA driver

Package: logcheck Version: 1.2.62 Severity: wishlist Here are two rules for ddclient, a client for dynamic IP services such as DynDNS or DynIP: ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ ddclient\[[[:digit:]]+\]: SUCCESS: updating [._[:alnum:]-]+: good: IP address set to [:[:xdigit:].]+$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ ddclient\[[[:digit:]]+\]: WARNING: forcing update of [._[:alnum:]-]+ from

Package: logcheck Version: 1.2.43a Severity: wishlist The conf file currently says # Should the hostname of the generated mails be fully qualified? FQDN=1 I suggest rewording that to # Should the hostname in the subject of the generated mails be fully qualified? FQDN=1 The current wording led me to believe that the sender, and perhaps recipient (if otherwise unqualified) of the emails generated

Hi gang, While writing a script that uses logtail, I noticed that logtail assumes nothing interesting happened between its last invocation and the rotation, which means that exciting bits of data could be lost. This seems a bit dodgy (correct me if I'm wrong about how it works!) so I made a dodgy patch to logtail that checks for the existence of $logfile.0, which on Debian seems to always be

Package: logcheck Version: 1.2.32 Severity: wishlist /etc/cron.daily/sysklogd restarts syslogd at the end of the script. This causes a daily log message, currently missed by logcheck: Jan 14 06:55:22 pyloric syslogd 1.4.1#16: restart (remote reception). I'm currently using this regex in ignore.server.d/local-syslogd: ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslogd 1\.4\.1#16: restart \(remote

Package: logcheck Version: 1.2.41 Problem: Logcheck try to detect if log file have been rotate or not by file size way. Possible attack: - current log file (sizeA) - run logcheck, (logcheck/logtail put inode in offsetfile), offset=sizeA - [attacker run attack 1] - run logrotate - [attacker run attack 2] - run logcheck may don't detect the rotation and don't check the log for attack 1

Package: logtail Version: 1.2.33 Severity: normal Hi... Logtail should not output error messages to standard output, since this violates the principle of least surprise. In particular, my application was broken by the semantics of logtail changing in version 1.2.21 (when you added switches for the default arguments to logtail). I think this was a bad move -- you broke an interface used by

Package: logcheck Version: 1.2.34 Severity: wishlist I have a couple of home-made logcheck ignore files, and happened to have one unescaped (and unmatched) `(' in one of the filter lines. Because of this, cron sent a mail with the body "grep: Invalid regular expression" - the subject is the command in the "2 * * * *" line in /etc/cron.d/logcheck, of course. It would be

Package: logtail Version: 1.2.68 Severity: normal Hi, logtail does not cleanly update from logtail2: $ sudo dpkg --install /var/cache/apt/archives/logtail_1.2.68_all.deb (Reading database ... 26564 files and directories currently installed.) Unpacking logtail (from .../logtail_1.2.68_all.deb) ... dpkg: error processing /var/cache/apt/archives/logtail_1.2.68_all.deb (--install): trying to

Package: logcheck Version: 1.2.26 Severity: wishlist Please add following bind9 server messages to ignore: i.e from below, everything that includex "zone.*loaded" + the other messages. Aug 16 20:24:27 ns named[3350]: shutting down: flushing changes Aug 16 20:24:27 ns named[3350]: stopping command channel on 127.0.0.1#953 Aug 16 20:24:27 ns named[3350]: stopping command channel on

Package: logcheck Version: 1.2.41 Severity: wishlist Hi folks, thanks for your work maintaining logcheck, it works well. When my users read their mail using imap (usually via squirrelmail, not sure about other clients) I get a message like this in the log: Aug 22 21:03:32 phoenix imapd[6551]: Moved 11323 bytes of new mail to /home/winky/mail/mbox from /var/spool/mail/winky host= localhost

Package: logtail Version: 1.2.61 Severity: important Recently logcheck stopped working on my system and after running it manually I traced it to logtail2... I'd recently been forced to delete the archived logs on my system in order to make some space and that appears to confuse logtail2 completely... e.g.: root at macaroni:~# logtail2 -t /var/log/syslog Cannot get /var/log/syslog.1.gz mtime: