Spam detection software, running on the system "azbox.underhanded.org", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Package: cron Version: 3.0pl1-100 Followup-For: Bug #206948
Issues with Cron and apparently PAM->LDAP seem to be still occuring in recent
packages. We had a cluster of machines apparently have cron stop launching
scripts silently, although I believe the daemon itself was still running.
The closest thing I could track it down to was this issues here, although
I am still digging deeper. [...]
Content analysis details: (10.6 points, 7.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-3.0 NO_RELAYS Informational: message was not relayed via SMTP
0.5 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.5313]
-0.0 NO_RECEIVED Informational: message has no Received headers
13 AWL AWL: From: address is in the auto white-list
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Administrator <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: cron: Cron still silently dying with ldap
Message-ID: <[EMAIL PROTECTED]>
X-Mailer: reportbug 3.38
Date: Thu, 06 Sep 2007 15:18:18 +0000
Package: cron
Version: 3.0pl1-100
Followup-For: Bug #206948
Issues with Cron and apparently PAM->LDAP seem to be still occuring in
recent packages. We had a cluster of machines apparently have cron stop
launching scripts silently, although I believe the daemon itself was
still running. The closest thing I could track it down to was this
issues here, although I am still digging deeper.
Although this has apparently been pegged as "PAM or LDAP needs to address this",
is there any chance of cron itself handling the signal or lack therof
gracefully and not segfaulting? And maybe sending a log message to
track?
Failing that, should Debian patch one package or another despite ldap
not wanting to handle signals in the interest of Debian packages working
cohesively? I'd imagine that just a few people who use LDAP also use
CRON.
This is a fairly old bug, so I'm not sure of the progress if any on it,
or if it was going to be left open indefinitely in the hopes that one of
the other packages would come around. Should I be opening this bug
against another package? I didn't because cron is the program that is
dying, but I will if needed. If you need any particular debugging
output or whatever that you don't already have, let me know. This has
caused some fairly serious headaches for myself and others until we realized
what was going on, and it would be nice to prevent it from happening to others
in the future.
Also, you may want to mark 260789 and possibly 332761 as duplicates of
this bug.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-1-686 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages cron depends on:
ii adduser 3.104 add and remove users and groups
ii debianutils 2.23.1 Miscellaneous utilities specific t
ii libc6 2.6.1-1 GNU C Library: Shared libraries
ii libpam0g 0.79-4 Pluggable Authentication Modules l
ii libselinux1 2.0.15-2+b1 SELinux shared libraries
ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip
Versions of packages cron recommends:
ii exim4 4.67-7 meta-package to ease Exim MTA (v4)
ii exim4-daemon-light [mail-tran 4.67-7 lightweight Exim MTA (v4) daemon
-- no debconf information
