Your message dated Tue, 18 Aug 2009 08:37:32 -0400
with message-id <[email protected]>
and subject line Re: Bug#515156: Same bug after removal + reinstall
has caused the Debian Bug report #515156,
regarding logcheck: fails to run after upgrade from etch to lenny
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
515156: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515156
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: logcheck
Version: 1.2.69
Severity: grave
Justification: renders package unusable
Hi,
I've just upgraded a box from Etch to Lenny and my logcheck broke.
I'm getting mails like this from cron:
From: logcheck system account <[email protected]>
Warning: If you are seeing this message, your log files may not have been
checked!
Details:
Failed to get lockfile: /var/lock/logcheck/logcheck.lock
So I started investigating...
/var/lock/logcheck is owned by root:root and is drwxr-xr-x, so the logcheck
user can't write in there.
logcheck.postinst contains this:
# Set Permissions on install, not upgrade
if [ ! -n "$2" ]; then
...
# just in case
chown logcheck /var/lock/logcheck > /dev/null || true
fi
So we chown the dir to logcheck only on fresh installs, just in case, huh?
/var/lock/logcheck is in the package, thus dpkg is smart and sets it to
root:root again on upgrade. Et voila, we can't lock anymore.
IMHO the permission setting should not be conditional here.
Regards
Evgeni
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.28-x31-1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages logcheck depends on:
ii adduser 3.110 add and remove users and groups
ii bsd-mailx [mailx] 8.1.2-0.20081101cvs-2 A simple mail user agent
ii cron 3.0pl1-105 management of regular background p
pn lockfile-progs <none> (no description available)
pn logtail <none> (no description available)
ii mailx 1:20081101-2 Transitional package for mailx ren
ii masqmail [mail-tra 0.2.21-4 A mailer for hosts without permane
ii sysklogd [system-l 1.5-5 System Logging Daemon
Versions of packages logcheck recommends:
pn logcheck-database <none> (no description available)
Versions of packages logcheck suggests:
pn syslog-summary <none> (no description available)
--- End Message ---
--- Begin Message ---
Version: 1.3.3
On Tue, Aug 18, 2009 at 08:15:28AM +0200, martin f krafft wrote:
> I don't think this is the right solution. With
> f573efec2645cd78dcc7ed5726106588f378acaa I removed the lock
> directory from the package, but forgot the postinst stuff. This is
> due to policy requiring /var/lock directories to be empty. Thus,
Ah, you're right, I missed that.
> logcheck needs to create the lock directory at runtime (which it
> does), and this is the place to fix the ownership and permissions.
I doubt that logcheck would be able to fix anything while running as the
logcheck user.
Still, you're right: this is a silly solution for unstable, if only
because the lock directory will be gone anyway following an upgrade to
1.3.3, so there's nothing there to fix.
--
revision 1.17.2.7
date: 2001/05/31 21:32:44; author: branden; state: Exp; lines: +1 -1
ARRRRGH!! GOT THE G** D*** SENSE OF A F******* TEST BACKWARDS!
--- End Message ---
_______________________________________________
Logcheck-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/logcheck-devel
