similar to: Bug#509885: does not cleanly update from logtail2

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:

Hello, logtail 1.2.60. logtail2 has a hardcoded '.gz' suffix during various checks of rotated archive logfiles, but if you use bzip2 for compressing them, it fails, of course. -- Micha? J?czalik, +48.603.64.62.97 INFONAUTIC, +48.33.487.69.04

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

Processing commands for control at bugs.debian.org: > forwarded 509885 http://bugzilla.xfce.org/show_bug.cgi?id=4763 Bug#509885: does not cleanly update from logtail2 Noted your statement that Bug has been forwarded to http://bugzilla.xfce.org/show_bug.cgi?id=4763. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system

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: logtail Version: 1.2.52 Severity: normal Tags: patch Hi, When a logfile is rotated, logtail misses the lines logged between the last logtail run and the logfile rotation. The attached patch allows to set an alternate logfile that logtail tries to use as the old logfile if the inode has changed. It can be used as: logtail -f /var/log/syslog -a /var/log/syslog.1 (Please note that this

Hiya Karl (and everybody else), I noticed today that ices 2.0-kh60a came out last January, and opted to give it a try. Unfortunately, it just wouldn't work at all, so I had to back down to 2.0-kh60. What I get in my log is this: [2006-04-21 21:16:18] DBUG om_shout/check_shout_connected Time we started stream on ice.imars.net:8000/cigr.ogg [2006-04-21 21:16:19] EROR

hi, i am desperately trying to get this version of ices up and running on debian etch. i used the apt repository at http://www.fbriere.net/debian/ices2/ but i found this also affects the "official" source package at http://mediacast1.com/~karl/ when i try to run an edited version of either the example file provided with the source package or the deb at /usr/share/doc/ices2-kh/ i

Package: logcheck Version: 1.2.39 Severity: normal Since I've upgraded my servers to sarge, I'm getting mail every hour for stuff that was duly included in /etc/logcheck/logcheck.ignore. Turns out that sarge's version no longer reads that file. If this was a conscious decision, then there should be some warning about this when upgrading (via debconf of NEWS.Debian). Also, the

Package: logcheck-database Version: 1.2.61 Severity: wishlist File: /etc/logcheck/ignore.d.server/proftpd Two weeks ago, I got a rush of these: Sep 8 12:37:07 goretex proftpd: PAM-listfile: Refused user news for service proftpd (Apparently, fail2ban managed to miss those.) This is triggered by pam_listfile, which is used by proftpd (and other FTP daemons) to block users listed in

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

On Sun, 2005-02-20 at 12:15, Fr?d?ric Bri?re wrote: > I've been running ices2 like this 24/7 for months now, only restarting > it once a week for log rotation. Never had a problem since. setting <logsize> will cause an automatic log rotation when a certain file size has been reached. It renames <logfile> to <logfile>.1 then opens a new file <logfile> karl.

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

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

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

hi everyone! currently, karl's branch of ices has a number of interesting features that the ices release does not: * jack support (very important for a number of users i know, and generally cool in terms of interoperability) * really nice metadata updates and on-the-fly savefile changes * runner threads for load distribution on smp boxen * on-the-fly switching of input sources (useful

Hi everybody, I'm in charge of an ices2 setup that's broadcasting a local radio station on the Net, and I'm currently under fire because one of our streams has been down twice in two days, forcing me to restart ices2 on each occasion. Our client is understandably unhappy about this. OUR SETUP: I've got ices2 installed on a local machine, broadcasting to an icecast server across

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

hi everyone, congratulations on the release of icecast 2.1.0 I presume this is the right place to post about iceS. please correct if wrong. I have a two instance setup, and have been finding that after a network error occurs, the instance does not reconnect. The source server is behind a linux NAT box. I have simulated the problem by using iptables REJECT with tcp-reset and here is the

Package: logcheck-database Version: 1.2.54 Severity: normal I recently created a bridge with the name xen-local. The DHCP server gets requests via this bridge. I got spammed with logcheck messages about DHCPREQUESTS and the lot because the name of the interface in the logcheck-database does not match on names with a dash in it. -- System Information: Debian Release: 4.0 APT prefers stable