Red Hat Bugzilla – Bug 712611
'crontab' loops on DNS if nscd not running
Last modified: 2011-12-10 15:04:53 EST
Description of problem: The 'crontab' program loops forever doing DNS lookups if the nscd service is not running.
Version-Release number of selected component (if applicable):
How reproducible: every time on this host.
Steps to Reproduce:
1. As root, enter "crontab -l". ("strace crontab -l" is fun too.)
2. Make coffee, read a book, ^C
3. service nscd start
3. re-enter step 1 command and get results.
stract crontab -l shows endless loop of DSN requests.
list of root's crontab. (I've been editing /var/spool/cron/root by hand and restarting crond to work around it.)
Additional info: This machine has been upgraded from Fedora 6, 7, 8, 9, 10, 11, 13, to 15, but I've "yum -y reinstall cronie" with no improvement.
This is most likely not a bug in cronie. Can you please attach your /etc/nsswitch.conf, /etc/pam.d/system-auth, /etc/pam.d/password-auth, /etc/pam.d/crond files?
Created attachment 525322 [details]
Created attachment 525324 [details]
Created attachment 525325 [details]
Created attachment 525326 [details]
I'm suspecting the pam_krb5 to be the culprit. If you temporarily disable kerberos with authconfig: 'authconfig --disablekrb5 --update', does it help?
Here's an annotated 'history' of my recent commands to test whether
'authconfig --disablekrb5 --update' affects things:
913 cp -av pam.d pam.d-orig
Backup my /etc/pam.d
914 crontab -l
Test. (nscd was running.) This worked fine, as expected.
915 service nscd stop
916 crontab -l
As expected, this never returned. Had to ^C out. So, the system is still exhibiting the problem behavior before any changes.
917 service nscd start
918 crontab -l
...and it works again after restarting nscd. So far no surprises.
Now for the real test....
919 authconfig --disablekrb5 --update
920 crontab -l
nscd is still running; this worked fine.
921 service nscd stop
922 crontab -l
This failed. Again, had to ^C. So disabling krb5 via authconfig didn't fix anything.
923 diff pam.d pam.d-orig
924 diff -u pam.d pam.d-orig
pam.d files were different. Not unexpected.
925 authconfig --enablekrb5 --update
926 diff -u pam.d pam.d-orig
pam.d files are all back to their original state.
927 crontab -l
This now works! Because...
929 service nscd status
930 service nscd stop
It turns out (after a little experimenting) that
'authconfig --enablekrb5 --update' has the side effect of activating nscd, which I didn't expect. So I stopped it again.
931 crontab -l
And this fails again, either with or without krb5 enabled as long a nscd is not running.
(In reply to comment #6)
> I'm suspecting the pam_krb5 to be the culprit. If you temporarily disable
> kerberos with authconfig: 'authconfig --disablekrb5 --update', does it help?
There is also pam_access in the crond. It normally should not be doing "looping DNS requests" but what is in your /etc/security/access.conf? Also when you look into the strace, what is it looking up?
(In reply to comment #8)
> There is also pam_access in the crond. It normally should not be doing "looping
> DNS requests" but what is in your /etc/security/access.conf? Also when you look
> into the strace, what is it looking up?
That's it! My /etc/security/access.conf has about 140 lines of stuff that starts like this:
# Block all logins from China
-:ALL: 220.127.116.11/15 18.104.22.168/16 22.214.171.124/17 126.96.36.199/17 188.8.131.52/16 184.108.40.206/16 220.127.116.11/16 18.104.22.168/16 22.214.171.124/15
-:ALL: 126.96.36.199/15 188.8.131.52/15 184.108.40.206/13 220.127.116.11/15 18.104.22.168/16 22.214.171.124/16 126.96.36.199/14 188.8.131.52/13 184.108.40.206/15
-:ALL: 220.127.116.11/16 18.104.22.168/17 22.214.171.124/17 126.96.36.199/14 188.8.131.52/15 184.108.40.206/17 220.127.116.11/15 18.104.22.168/18 22.214.171.124/17
-:ALL: 126.96.36.199/15 188.8.131.52/14 184.108.40.206/13 220.127.116.11/16 18.104.22.168/15 22.214.171.124/15 126.96.36.199/15 188.8.131.52/15 184.108.40.206/15
-:ALL: 220.127.116.11/13 18.104.22.168/12 22.214.171.124/15 126.96.36.199/15 188.8.131.52/15 184.108.40.206/15 220.127.116.11/13 18.104.22.168/13 22.214.171.124/15
... it goes on. That's 1249 subnets. Removing them makes 'crontab -l' run instantly with nscd stopped. With nscd running and all those "-:ALL:" lines in place, there is a slight delay of maybe a second that I'd not really noticed until it was gone.
The strace does show it hitting my nameserver, presumably once for each denied subnet spec. But why would a local 'crontab -l' need to hit the nameserver for each subnet mentioned in those "-:ALL:" lines?
Moving the "+:ALL:LOCAL" line above the "#Block all logins from China" section (it was below before) makes 'crontab -l' start quickly regardless of nscd. D'oh!
Still, seems strange that DNS would get hit for all those subnets.
You can add debug option to pam_access and see what it tries to do. But I actually think it does not try to resolve the china netmasks but the local tty name again and again. It could probably be made more clever to avoid the DNS lookup on the tty name and do it only on hostnames perhaps also caching the result. Unfortunately nobody expected 1249 subnets in access.conf.
pam-1.1.5-1.fc16 has been submitted as an update for Fedora 16.
pam-1.1.5-1.fc15 has been submitted as an update for Fedora 15.
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pam-1.1.5-1.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
pam-1.1.5-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
pam-1.1.5-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.