Bug 124882 - (IT_56879) crond dies after ldap restarted when user edits crontab
crond dies after ldap restarted when user edits crontab
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: vixie-cron (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
: 156671 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-31 21:17 EDT by Ian Clark
Modified: 2007-04-18 13:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-04 16:11:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This is th /etc/pam.p/system-auth of one of the machines (1.14 KB, text/plain)
2004-05-31 21:21 EDT, Ian Clark
no flags Details

  None (edit)
Description Ian Clark 2004-05-31 21:17:13 EDT
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)
Comment 1 Ian Clark 2004-05-31 21:21:34 EDT
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
Comment 2 Ian Clark 2004-05-31 21:24:56 EDT
Just remembered - These machines are not running 'nscd' as it was 
disabled to get around other ldap / pam issues.
Comment 3 Juergen Wiebe 2004-06-04 09:07:14 EDT
Hello everybody,

we have the same Problem with LDAP / CRON Daemon.
Comment 4 Ian Clark 2004-06-06 08:12:35 EDT
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.
Comment 5 Florian La Roche 2004-10-18 06:35:19 EDT
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
Comment 7 Gunther Schlegel 2004-11-29 06:32:40 EST
I seem to have that problem on RHEL3ES U3
Comment 9 Jason Vas Dias 2004-12-10 11:51:44 EST
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.

Comment 10 David Lehman 2004-12-10 12:00:48 EST
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.
Comment 11 Jason Vas Dias 2004-12-10 12:33:45 EST
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).  
Comment 12 David Lehman 2004-12-10 12:45:26 EST
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.
Comment 13 Jason Vas Dias 2004-12-10 18:24:24 EST
I've just heard from Nalin <nalin@redhat.com> that he is implementing
the nss_ldap fix for RHEL-3 ASAP, so we won't have to do a workaround
in vixie-cron.
Comment 19 Jason Vas Dias 2005-05-04 10:44:25 EDT
*** Bug 156671 has been marked as a duplicate of this bug. ***
Comment 20 Eric Paris 2005-08-11 10:58:34 EDT
Did we decide this was fixed?  Should we close?
Comment 21 Bill Nottingham 2006-08-04 16:11:12 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.