Description of problem: If slapd is restarted after crond is started, when a user modifies their crontab, crond dies next time it tries to start a job. The user can be both a local user in /etc/passwd or a user in the LDAP server. On both Redhat 9.0 machines I tested this on the LDAP server was on the same machine as crond. ==> /var/log/cron <== Jun 1 09:32:48 smdl-c-103 crontab[17804]: (c76627j) BEGIN EDIT (c76627j) Jun 1 09:32:51 smdl-c-103 crontab[17804]: (c76627j) REPLACE (c76627j) Jun 1 09:32:51 smdl-c-103 crontab[17804]: (c76627j) END EDIT (c76627j) Jun 1 09:33:01 smdl-c-103 crond[17506]: nss_ldap: reconnecting to LDAP server... Jun 1 09:33:01 smdl-c-103 crond[17506]: nss_ldap: reconnected to LDAP server after 1 attempt(s) crond has died at this point This DOESN'T happen if slapd isn't restarted after crond was started. Version-Release number of selected component (if applicable): vixie-cron-3.0.1-74 How reproducible: Every Time Steps to Reproduce: 1. /etc/init.d/crond restart 2. /etc/init.d/ldap restart 3. Any user edits crontab ie crontab -e Actual results: crond has died at this point Expected results: crond continuies merrily along Additional info: If I attach to the running crond process with gdb I see a SIGPIPE at the time when crond should be kicking off the next lot of jobs (gdb) cont Continuing. Program received signal SIGPIPE, Broken pipe. 0xffffe002 in ?? () (gdb)
Created attachment 100728 [details] This is th /etc/pam.p/system-auth of one of the machines This file was tweaked because of ldap issues logging into the box when primary (local) LDAP server failed
Just remembered - These machines are not running 'nscd' as it was disabled to get around other ldap / pam issues.
Hello everybody, we have the same Problem with LDAP / CRON Daemon.
I compiled crond from vixie-cron-3.0.1-74.src.rpm and got this from gdb: Program received signal SIGPIPE, Broken pipe. 0x40048c81 in sigprocmask () from /lib/libc.so.6 (gdb) where #0 0x40048c81 in sigprocmask () from /lib/libc.so.6 #1 0x4016bbee in _nss_ldap_leave () from /lib/libnss_ldap.so.2 #2 0x4016d720 in _nss_ldap_getbyname () from /lib/libnss_ldap.so.2 #3 0x4016e55b in _nss_ldap_getpwnam_r () from /lib/libnss_ldap.so.2 #4 0x400c4636 in getpwnam_r@@GLIBC_2.1.2 () from /lib/libc.so.6 #5 0x400c4170 in getpwnam () from /lib/libc.so.6 #6 0x08049fe2 in process_crontab (uname=0xbfffdee0 "tuser", fname=0xbfffdee0 "tuser", tabname=0xbfffdde0 "cron/tuser", statbuf=0xbfffe2b0, new_db=0xbfffe1e0, old_db=0xbfffe340) at database.c:256 #7 0x08049db1 in load_database (old_db=0xbfffe340) at database.c:168 #8 0x08049712 in main (argc=0, argv=0x0) at cron.c:124 #9 0x4003749d in __libc_start_main () from /lib/libc.so.6 (gdb) I believe this links it to Bug #: 112882 whish is SIGPIPES from ldap_nss.
Is this also happening with FC3test releases? We've updated most rpm packages and testing against the newest ones would also give some more information to us. Thanks a lot, Florian La Roche
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134567
I seem to have that problem on RHEL3ES U3
This should be fixed now that nss_ldap handles SIGPIPE ( bug #134567 ). Please retest with RHEL-3-U4 (vixie-cron-4.1-1_EL3, nss_ldap-207-11) - I believe the problem will not occur with these versions.
The nss_ldap fix has not been checked in (nss_ldap-207-11 is from U3). The problem is with nss_ldap, not vixie-cron, but it's still unresolved.
Aargh, sorry about that - it seems 'vixie-cron-4.1-1_EL3' is also not in RHEL-3-U4, even though I checked it in and issued an errata nearly a month ago. I guess I could make 'vixie-cron-4.1-2_EL3' do a signal(SIGPIPE, SIG_IGN) Dave, do you think that would help? (I can't reproduce this problem, as I have no U3 LDAP server to test with - I've not been able to make it occur on FC4/Rawhide with an FC3 LDAP server).
While ignoring SIGPIPE might be a workaround for vixie-cron, this is happening to other apps also (like ssh). I'd much rather get the nss_ldap fix in than make maintainers of other packages do nasty things like that to compensate. Incidentally, FC4/rawhide has a version of nss_ldap with this bug fixed, so it shouldn't be reproducible there.
I've just heard from Nalin <nalin> that he is implementing the nss_ldap fix for RHEL-3 ASAP, so we won't have to do a workaround in vixie-cron.
*** Bug 156671 has been marked as a duplicate of this bug. ***
Did we decide this was fixed? Should we close?
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED state for these products. However, we do want to make sure that nothing important slips through the cracks. If, in fact, these issues are not resolved in a current Fedora Core Release (such as Fedora Core 5), please open a new issues stating so. Thanks.