logcheck fails when auth.log.1.gz missing

Bug #149641 reported by JP Vossen on 2007-10-05
28
Affects Status Importance Assigned to Milestone
logcheck (Debian)
Fix Released
Unknown
logcheck (Ubuntu)
Undecided
Unassigned
Gutsy
Undecided
Unassigned

Bug Description

Binary package hint: logcheck

Problem
=======
Stock logcheck 1.2.61 under Mythbuntu (Gutsy) fails with a misleading error message when /var/log/auth.log.1.gz does not exist.

Failure email (misleading):
----- cut here -----
Subject: Logcheck: <hostname> 2007-10-05 15:02 exiting due to errors
Body:
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.es2361

Also verify that the logcheck user can read all files referenced in
/etc/logcheck/logcheck.logfiles!

declare -x HOME="/var/lib/logcheck"
declare -x LANG="en_US.UTF-8"
declare -x LOGNAME="logcheck"
declare -x MAILTO="root"
declare -x OLDPWD
declare -x PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
declare -x PWD="/var/lib/logcheck"
declare -x SHELL="/bin/sh"
declare -x SHLVL="1"
----- cut here -----

Note the temp dir has already been removed, so telling the user to check it is useless and confusing.

Reason
======
The Perl /usr/sbin/logtail2 script's sub determine_rotated_logfile uses '/usr/share/logtail/detectrotate/*.dtr' to figure out where previously rotated files might be. That code seems to come up with '/var/log/auth.log.1.gz' as a file to check. But if that file does not exist, logtail2 dies with "Cannot get /var/log/auth.log.1.gz mtime: No such file or directory" and that kills logcheck, producing the error above.

The actual logtail2 error is buried in $TMPDIR/logoutput/$(basename "$file"), which is a) not shown or mentioned in the error message email and b) automatically deleted unless you're manually running logcheck -t.

Possible Solution
=================
Instead of:
 if ($rotated_filename && inode($rotated_filename) == $inode) {

use something like this (NOT TESTED):
 if ($rotated_filename && -e $rotated_filename \
   && inode($rotated_filename) == $inode) {

Steps to Reproduce
==================
Backup your existing /var/log/auth* files!

$ date
Fri Oct 5 18:31:30 EDT 2007

$ cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu gutsy (development branch)"

$ whoami
logcheck

$ logcheck -v
logcheck 1.2.61

$ ls -l /var/log/auth*
-rw-r----- 1 syslog adm 120382 2007-10-05 18:17 /var/log/auth.log
-rw-r----- 1 syslog adm 51802 2007-09-30 06:47 /var/log/auth.log.0

$ /usr/sbin/logtail2 -t -f /var/log/auth.log -o /tmp/offset.var.log.auth.log > /dev/null
Cannot get /var/log/auth.log.1.gz mtime: No such file or directory

$ sudo touch /var/log/auth.log.1.gz [sudo] password for logcheck:

$ ls -l /var/log/auth*
-rw-r----- 1 syslog adm 120850 2007-10-05 18:25 /var/log/auth.log
-rw-r----- 1 syslog adm 51802 2007-09-30 06:47 /var/log/auth.log.0
-rw-r--r-- 1 root root 0 2007-10-05 18:26 /var/log/auth.log.1.gz

$ /usr/sbin/logtail2 -t -f /var/log/auth.log -o /tmp/offset.var.log.auth.log > /dev/null

$ sudo rm /var/log/auth.log.1.gz

$ ls -l /var/log/auth*
-rw-r----- 1 syslog adm 120850 2007-10-05 18:25 /var/log/auth.log
-rw-r----- 1 syslog adm 51802 2007-09-30 06:47 /var/log/auth.log.0

$ /usr/sbin/logtail2 -t -f /var/log/auth.log -o /tmp/offset.var.log.auth.log > /dev/null
Cannot get /var/log/auth.log.1.gz mtime: No such file or directory

TEST CASE:
1. sudo apt-get install logtail=1.2.61
2. sudo mv /var/log/auth.log.1.gz /var/log/auth.log.1.gz.bak
3. /usr/sbin/logtail2 -t -f /var/log/auth.log -o /tmp/offset.var.log.auth.log > /dev/null
Cannot get /var/log/auth.log.1.gz mtime: No such file or directory
4. sudo apt-get install logtail=1.2.61ubuntu0.1
5. /usr/sbin/logtail2 -t -f /var/log/auth.log -o /tmp/offset.var.log.auth.log > /dev/null
6. sudo mv /var/log/auth.log.1.gz.bak /var/log/auth.log.1.gz

In 3. an error is thrown, which should not appear in 5. anymore.

See this thread: http://lists.alioth.debian.org/pipermail/logcheck-devel/2004-October/000924.html

"""
> # chown -R logcheck:logcheck /var/lib/logcheck
This resolved the issue on my box...
let me know if there is anything I can do to help find the bug...
"""

JP Vossen (jp-jpsdomain) wrote :

Yeah, I checked that. That was not the problem for me. My problem is as outlined above in "Steps to Reproduce." If "/var/log/auth.log.1.gz" does not exist, logcheck fails with a misleading message. If "/var/log/auth.log.1.gz" does exist, logcheck works. See above for "Possible Solution."

Daniel Hahler (blueyed) on 2007-10-19
Changed in logcheck:
assignee: nobody → blueyed
status: New → In Progress
Daniel Hahler (blueyed) wrote :

This debdiffs picks the fix for this bug and bug 153447 from version 1.2.62 in Debian unstable.
These bugs should get fixed in Hardy by syncing.

Changed in logcheck:
assignee: blueyed → nobody
status: In Progress → Confirmed
Daniel Hahler (blueyed) wrote :

Updated changelog, because bug 153447 appears to be a duplicate. The dependency fix seems sensible though.

Changed in logcheck:
status: Unknown → Fix Released
Leon van der Ree (lvanderree) wrote :

I can (not surprisingly) confirm this bug on Ubuntu Gutsy as well.

A quick work around is to run:

# touch /var/log/auth.log.1.gz

Thanks for your bug-report, I would not had a clue otherwise, really misleading. Especially because because logcheck always worked before my clean install...

Ariel Faigon (ariel.faigon) wrote :

Note that fixing this bug is a necessary, but not a sufficient condition to make logcheck work on gutsy.

After fixing this manually, I still get one more failure later from logtail:
       File /var/log/syslog.offset cannot be created. Check your permissions: Permission denied

To solve this problem too, I had to manually create the offset files and make them owned by logcheck:
        sudo touch /var/log/syslog.offset /var/log/auth.log.offset
        sudo chown logcheck /var/log/syslog.offset /var/log/auth.log.offset

In addition, logtail when running as 'logcheck' cannot read files under /var/log which aren't world readable,
Fixing this required giving logtail a setgid and group adm:

        sudo chgrp adm /usr/sbin/logtail
        sudo chmod g+s /usr/sbin/logtail

only after fixing all the above logcheck finally works for me on gutsy.

Ariel Faigon (ariel.faigon) wrote :

Apologies, but I have to correct/improve myself on the previous comment.
I have a feeling I was running an older version of logcheck.

If I run logcheck from cron with full path (certainly the ubuntu version) like this:

        sudo -u logcheck /usr/sbin/logcheck -op
        (given that I add /usr/bin/logcheck to /etc/sudoers with NOPASSWD)

or alernatively:
        Add a setuid logcheck to /usr/sbin/logcheck:
               sudo chown logcheck /usr/sbin/logcheck
               chmod u+s /usr/sbin/logcheck

Then, the offset files get created/updated under:
        /var/lib/logcheck/offset.var.log.<filename>

and the 'touch/chown' fix (step 2 above) is not necessary.

It is all hairy, but overall, the setuid checklog, setgid adm looks like the cleanest solution.
What is required is for all of the 3 conditions to be true:

     - /usr/sbin/logcheck can read all its configs under /etc/logcheck/*/*
     - /usr/sbin/logtail can write offset files under /var/lib/logcheck/*
     - /usr/sbin/logtail can read files under /var/log (some of which are user:group root:adm and not world readable)

Sorry.

Daniel Hahler (blueyed) wrote :

This bug should be fixed in Hardy.

I'm not sure if this is important enough for a Gutsy-SRU. Please let me know: the patch is available above.

Changed in logcheck:
status: Confirmed → Fix Released
JP Vossen (jp-jpsdomain) wrote :

How big a deal is it to fix for Gutsy? On one hand, someone using logcheck is arguably more likely to check for bugs and/or just figure it out. OTOH, some might give up, and it's something that doesn't Just Work. :-(

Unless the LoE is large, I'd vote to fix it for Gutsy.

Mathieu Doidy (bugs-roulaize) wrote :

I just did a fresh install of Gutsy and logcheck is completely broken. How could it be worse if the patch was applied?
Reading this bug report, it is not clear what needs to be done from an end-user point of view between the patch coming from Debian and the comments from Ariel.
I vote for the fix to be applied after being tested on systems upgraded from previous releases.

Daniel Hahler (blueyed) wrote :

I've tried several times already to have someone confirm the nomination for Gutsy.
There's a patch which fixes this. You can get a version with the patch applied from my PPA (http://launchpadlibrarian.net/10148072/logcheck_1.2.61ubuntu0.1~ppa1_all.deb).
The bug is not present in Ubuntu Dapper (logtail2 was not present there yet). I have not checked Feisty or Edgy.

dAniel hAhler wrote:
> I've tried several times already to have someone confirm the nomination for Gutsy.

What is required for that? Is that something we can do?

Daniel Hahler (blueyed) wrote :

Although it's fixed for hardy, I'm setting this back to "Fix committed", so the bug shows up for ubuntu-sru.. :/

Changed in logcheck:
status: Fix Released → Fix Committed
Martin Pitt (pitti) on 2007-10-27
Changed in logcheck:
status: Fix Committed → Fix Released
assignee: nobody → blueyed
status: New → In Progress
Daniel Hahler (blueyed) on 2007-10-28
Changed in logcheck:
status: In Progress → Fix Committed
assignee: blueyed → nobody
status: Fix Committed → Confirmed
aliet (alietss) wrote :

Guys, just to remember that logcheck is part of main, and is completely broken, this goes against ubuntu policies, this update is a must...

Martin Pitt (pitti) wrote :

This looks good for me as an SRU. It is a regression, and logcheck is sensitive infrastructure which should not just break.

Upload sponsored and accepted into gutsy-proposed. Please update the description to include the test case, as described on the recently updated https://wiki.ubuntu.com/StableReleaseUpdates. Thank you!

Changed in logcheck:
status: Confirmed → Fix Committed
Daniel Hahler (blueyed) on 2007-11-09
description: updated
Pedro Villavicencio (pedro) wrote :

Verification done after following the test case:

a- after following the steps 1 to 3 from the test case: a "No such file or directory" error is thrown.
b- after following the steps 4 to 5 from the test case: no error is thrown, according to this the bug is fixed, thanks.

Martin Pitt (pitti) wrote :

Copied to gutsy-updates.

Changed in logcheck:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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