I'm not sure it is due to vixie-cron, but since my last update (2006/06/03), all mails sended by cron are blocked : # crontab -l | tail -n 1 */5 9 * * * echo "test" # LANG= date && ps axfu | tail -n 4 Thu Jun 8 09:56:27 AST 2006 root 9511 0.0 0.1 6896 1848 ? S 09:50 0:00 /usr/sbin/sendmail -FCronDaemon -odi -oem -oi -t root 9530 0.0 0.1 6872 1832 ? S 09:50 0:00 \_ /usr/sbin/postdrop -r root 9813 0.0 0.1 6896 1852 ? S 09:55 0:00 /usr/sbin/sendmail -FCronDaemon -odi -oem -oi -t root 9851 0.0 0.1 6876 1836 ? S 09:55 0:00 \_ /usr/sbin/postdrop -r # equery l vixie-cron [ Searching for package 'vixie-cron' in all categories among: ] * installed packages [I--] [ ] sys-process/vixie-cron-4.1-r9 (0) My postfix work well, and nothing changed recently.
I have to add that I tried to downgrade to 4.1-r8 without success.
I'd just like to weigh in on this - the upgrade to r9 has broken all emails from cron, and as Cristophe has mentioned, a revert to r8 doesn't fix it either. I've gone through and checked permissions everywhere, but nothing seems to be out of whack. What will happen is that vixie-cron will keep spawning "sendmail -FCronDaemon -odi -oem -oi -t" and "postdrop -r" processes time and time again, but none of them will finish. As a result, I've had as many as 650+ processes running before I managed to kill all of the rogue sendmail and postdrop processes off. I've done manual mails to root, and there's no problem there: postfix is receiving and processing mails properly. I can only assume that the problem is on vixie-cron's end, perhaps with the processing of the output from the cron job into standard out for the mail process? Perhaps it is not terminating the stdout correctly?
I'm really glad to learn that I'm not alone :-) And I think too about mail termination.
I have the same bug, reverting to r8 was inefficient too, I tried to dedug without success, but I cannot figure out what made the bug persistent to reverting, very few seems to change between r8 and r9, and nothing persistent. Change of code are not persistent, some change of say pam policy can be persistent. But the only one I have seen is between r7 and r8, and even that don't seem to be the cause. I suppose that every user of vixie-cron 4.1-r9 has not this bug. Otherwise this page would have been multiplied by one hundred. What make us special? I use ldap for authentification, is it also your case?
I use LDAP too
After some poking, I can say the problem is related to nsswitch.conf and cron. If you remove the "ldap" entry from the passwd, group, and shadow lines (thus making LDAP authentication useless!), cron works just fine in terms of sending out emails. I've gone back and forth in several variations in this file, but anytime ldap is present, that is when it fails.
I went thru the same process than Jeremy with the same results, so I infer the bug is not coming from vixie-cron but from nss_ldap, it is why reverting vixie-cron to a previous version does not help. I used nss_ldap-249, so I tried nss_ldap-250-r1 with the same results, but when reverting first to nss_ldap-226 and then to nss_ldap-239-r1 the mails from vixie-cron-4.1-r9 are working as they are expected to do. May be this bug might be reaffected to nss_ldap herd? May be we have to look at their bug list for something similar.
I confirm that. I downgraded yesterday to nss_ldap-239-r1 and cron send mail now.
#pgrep sendmail 23107 #strace -p 23107 read(0, #ls -l /proc/23107/fd/0: /proc/23107/fd/0 -> socket:[24260987] #netstat -et | grep 24260987 tcp 0 0 localhost:47560 localhost:ldap ESTABLISHED root 24260987 So why is it trying to read the message to send from ldap?
Thanks Christophe for your downgrade tip. I can confirm this bug too. Every vixie-cron mail was lost in my system and created an empty file in '/var/spool/postfix/maildrop'.
It works now for me with sys-auth/nss_ldap-249 Before upgrading nss_ldap again, I just recompiled a lot of ebuilds because of all warnings in openldap emerge logs like : revdep-rebuild --library liblber.so.2.0.130 revdep-rebuild --library libldap.so.2.0.130 revdep-rebuild --library libldap_r.so.2.0.130 revdep-rebuild --library liblber-2.2.so.7 revdep-rebuild --library liblber-2.2.so.7.0.21 revdep-rebuild --library libldap-2.2.so.7 revdep-rebuild --library libldap-2.2.so.7.0.21 revdep-rebuild --library libldap_r-2.2.so.7 revdep-rebuild --library libldap_r-2.2.so.7.0.21 and removing all those libs after. I don't know if it is dependent.
I'm talking about net-nds/openldap-2.3.24-r1
I'd like to chime in that I also have experienced this problem. Downgrading to nss_ldap-239-r1 solved the problem for me. I'd also like to point out that the problem isn't MTA-specific. I use ssmtp to relay through our organization's mail server and experience the same behavior as the postfix users. Cron would open a pipe to sendmail, but the sendmail process would hang indefinitely. As the pipe's buffer got filled up, the cron would silently sleep.
I'm also seeing this behaviour but it only seems to be affecting root. A normal user account with details in my ldap database continues to work fine. I've also noticed the first job executed by cron after starting the dameon generates an email as expected but any subsequent ones fail. Perhaps nss_ldap not returning cleanly after the first call?
(In reply to comment #14) > Perhaps nss_ldap not returning cleanly after the first call? With debugging enable in nss_ldap I have found that the first call completes ok but subsequent ones hang while doing ldap_search_st() (OpenLDAP call) in do_search_s() in ldap-nss.c. Although this call can be set to timeout using the timelimit parameter in /etc/ldap.conf the default is LDAP_NO_LIMIT, i.e. no timeout. Enabling the option in /etc/ldap.conf forces this function to return but doesn't fix the problem.
> It works now for me with sys-auth/nss_ldap-249 > Before upgrading nss_ldap again, I just recompiled a lot of ebuilds because of > all warnings in openldap emerge logs like : I already had openldap-2.3.24 and nss_ldap-249 but I don't in which order I installed them. But just to try, I recompiled nss_ldap to make sure that it was compiled and installed after opendldap. But I still have the problem. > I'm also seeing this behaviour but it only seems to be affecting root. For me, it affects all users. Another proof that it's related to ldap: restarting slapd kills all blocked sendmail processes (however the emails are still not sent)
A lot of problems have been reported with nss_ldap-249 250 you may want to look at http://robbat2.livejournal.com/199841.html. They refer mainly to nss_ldap timeout and I don't know if our cron problem is related. But these are fixed in ss_ldap-252. Marc
1. Hmm, if you explictly set an email address for vixie-cron to send to, does it work? 2. If you explictly set it to a username that IS in ldap, does it work? Would have been useful if somebody had CC'd the LDAP folk early on.
Yesterday, I added a MAILTO line for both a root cronjob and a regular (LDAP) user one, as sugested. This morning both users still have blocked sendmail/postdrop processes. So no luck there.
A solution that has fixed my problem is running the nscd daemon. Current versions of nss_ldap seem to be horribly broken without it - I found this out on my client systems when I upgraded to glibc 2.4
I don't have this problem anymore for a long time. May be could we close this bug ?
It's fixed for me too.
Who have to close the bug ? The opener (me) ?
thanks for the feedback - please reopen if problem persists. kind regards Thilo
