Logwatch looks for afpd output in "messages", not in log files that afpd writes to

Bug #752172 reported by dusanv
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
logwatch (Ubuntu)
Triaged
Low
Unassigned

Bug Description

[Impact]

Since the changeover to rsyslogd, logwatch has been looking in the wrong places for the logfiles it's supposed to monitor.

Logs that used to go to /var/log/daemon.log, /var/log/cron.log, and /var/log/messages, are now being logged to /var/log/syslog. This commit changes configurations in dist.conf/logfiles/ to point to /var/log/syslog.

[Test Case]

# lxc launch ubuntu-daily:cosmic tester
# lxc exec tester bash
# dhclient
# apt update
# apt dist-upgrade -y
# apt install -y logwatch

# echo "Sep 12 01:41:51 xxxxx named[838]: received control channel command 'refresh example.com'
Sep 12 03:34:10 xxxxx smartd[30161]: Monitoring 4 ATA and 0 SCSI devices
Sep 12 03:34:11 xxxxx smartd[30161]: Device: /dev/hdc, 463 Currently unreadable (pending) sectors
Sep 12 03:34:11 xxxxx smartd[30161]: Device: /dev/hdc, 1210 Offline uncorrectable sectors
Sep 12 03:34:11 xxxxx smartd[30161]: Device: /dev/hdd, 1430 Currently unreadable (pending) sectors
Sep 12 03:34:11 xxxxx smartd[30161]: Device: /dev/hdd, 1429 Offline uncorrectable sectors
Sep 12 09:00:00 xxxxx afpd[2383]: login noauth" >> /var/log/syslog

# logwatch --detail medium --range all --service named
# logwatch --detail medium --range all --service smartd
# logwatch --detail medium --range all --service afpd

* None of these commands will display anything.

[Regression Potential]

This has been broken since at least 2011. Logwatch currently doesn't report anything that isn't already pointing to syslog, so there should be no regression potential.

[Original Description]

Binary package hint: logwatch

This on Ubuntu 10.04.2 LTS, logwatch version 7.3.6.cvs20090906-1ubuntu2.1. The default logwatch configuration expects to find afpd log messages in the 'messages' log file (as per /usr/share/logwatch/default.conf/services/afpd.conf). afpd is logging to 'syslog', 'daemon' and 'auth' log files on Ubuntu so a Ubuntu-specific afpd configuration file should be present (/usr/share/logwatch/dist.conf/services/afpd.conf). That file should list the correct log files. Here's an example:

Title = "afpd"
LogFile = syslog
LogFile = daemon
LogFile = auth
*OnlyService = afpd
*RemoveHeaders

Related branches

Revision history for this message
James Page (james-page) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I confirmed this on a Natty install; logwatch configuration for this service has not changed since lucid.

The only difference is that the daemon log file is no longer used.

James Page (james-page)
Changed in logwatch (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
dusanv (dusanv) wrote :

Since most of what logwatch spews out for afpd on my machine are unmatched entries, I added another line to the config:

$afpd_ignore_unmatched = 1

Not sure whether you'd want that in the distro afpd.conf file but I'm mentioning it anyway.

Revision history for this message
Thomas Hood (jdthood) wrote :

In precise and quantal (as of today, 2 October 2012) the logwatch config still directs logwatch to look in messages.

tags: added: lucid natty precise quantal
summary: - Ubutu-specific afpd configuration missing
+ Logwatch looks for afpd output in "messages", not in log files that afpd
+ writes to
Revision history for this message
Craig (craig-st) wrote :

You should consider marking this bug as a duplicate of Bug #794727.

Revision history for this message
Robie Basak (racb) wrote :

Thanks Craig - I agree.

Changed in logwatch (Ubuntu):
assignee: nobody → Karl Stenerud (kstenerud)
description: updated
Changed in logwatch (Ubuntu):
status: Confirmed → In Progress
description: updated
Bryce Harrington (bryce)
Changed in logwatch (Ubuntu):
assignee: Karl Stenerud (kstenerud) → nobody
status: In Progress → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.