Description of problem: I have cron jobs that must run as usernames that only exist in LDAP. I see the "bad username" error because crond can be started before the LDAP server is reachable. The LDAP server is distinct from the server with the cron job. The issue is especially troublesome when both servers are VMs on the same host and booting up together. Version-Release number of selected component (if applicable): cronie-1.4.11-4.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. create a cron job with a username that only exists in LDAP 2. stop crond and the LDAP server (or otherwise make it unreachable) 3. start crond 4. start the LDAP server (or make it available again) Actual results: Logs show "crond[PID]: (CRON) bad username (/etc/cron.d/JOBNAME) Expected results: Ideally crond would periodically retry to establish the username identities each time the job comes due again, if they weren't already successfully established. Additional info:
That's strange. Bug with orphaned cronjobs was fixed by 1.4.8 release. The 1.4.11 release is also in RHEL-7, where this bug was verified as fixed. Could you still reproduce it?
I can indeed still reproduce it with cronie-1.4.10-7.fc19.x86_64. I just discovered another daily job that's not been run for the last 25 days or so because of this: # ls -art /var/log/cron* | xargs grep bad /var/log/cron-20140309:Mar 3 14:13:58 mdct-aos-master-f19 crond[300]: (CRON) bad username (/etc/cron.d/mdct-puppeteer-admin) /var/log/cron-20140309:Mar 3 14:13:58 mdct-aos-master-f19 crond[300]: (CRON) bad username (/etc/cron.d/mdct-puppeteer-admin) /var/log/cron-20140309:Mar 3 14:13:58 mdct-aos-master-f19 crond[300]: (CRON) bad username (/etc/cron.d/mdct-puppeteer-admin) /var/log/cron-20140323:Mar 18 14:33:19 mdct-aos-master-f19 crond[303]: (CRON) bad username (/etc/cron.d/mdct-puppeteer-admin) /var/log/cron-20140323:Mar 18 14:33:19 mdct-aos-master-f19 crond[303]: (CRON) bad username (/etc/cron.d/mdct-puppeteer-admin) /var/log/cron-20140323:Mar 18 14:33:19 mdct-aos-master-f19 crond[303]: (CRON) bad username (/etc/cron.d/mdct-puppeteer-admin)
Is there anything I can do to help move this bug along? As things stand, I've resorted to puppet pushing out a cron.daily job (as root) that restarts crond to minimize the damage this is causing on numerous systems.
I'm sorry I missed the needinfo. Anyway according our tests it's working. I do not know if we have different setting or what's the reason I can't reproduce it.
(In reply to Marcela Mašláňová from comment #4) > I'm sorry I missed the needinfo. Anyway according our tests it's working. I > do not know if we have different setting or what's the reason I can't > reproduce it. I would have to say then that your tests somehow do not cover the situation I described. Perhaps you have an insufficient elapsed time between steps 3 & 4? I still see this and require a cron.daily job to restart crond -- which is kludgey at best.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I see something similar on RHEL7. Systems are using sssd for users auth, However it seems crond is started before sssd in init process and then find users crontabs to be orphans and disable all. Restarting crond after startup is done fixes the problem. Is it possible in systemd service speak to order crond to start after sssd has made users visible on the systems?
Thanks, that explains the mystery. Cronie is probably missing this in unit file: After=nss-user-lookup.target Lukas, could you verify it's a proper fix?
We added: Before=systemd-user-sessions.service nss-user-lookup.target Wants=nss-user-lookup.target Very recently to sssd, as a matter of fact I just pushed that build to stable (it's sssd-1.11.6-3).
(In reply to Marcela Mašláňová from comment #8) > Thanks, that explains the mystery. > > Cronie is probably missing this in unit file: > After=nss-user-lookup.target > > Lukas, could you verify it's a proper fix? Yep, looks sane.
cronie-1.4.12-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/cronie-1.4.12-1.fc20
cronie-1.4.12-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/cronie-1.4.12-1.fc21
Package cronie-1.4.12-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cronie-1.4.12-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11067/cronie-1.4.12-1.fc20 then log in and leave karma (feedback).
Sadly cronie-1.4.12-1.fc20 does not resolve the issue for me. I installed this (and all other) updates, rebooted and still see "bad username" errors from crond that will go away simply by restarting crond. Would it really be so hard for cronie to just retest the validity of any failed user periodically?
There already is such functionality, but it is probably broken somehow for you. I need to find a reproducer on my system to debug this.
(In reply to Tomas Mraz from comment #15) > There already is such functionality, but it is probably broken somehow for > you. I need to find a reproducer on my system to debug this. If there's anything (tcpdump, strace, etc) I can provide to help, please let me know.
Oh crap! I just reread Jakub's comment #9 and realized I hadn't checked what release of sssd I had installed. Sure enough -3 was still only in our testing repo mirror. I upgraded from -2 to -3, rebooted and jobs seem to be firing now. I'm so sorry for the bad info. Granted, I've only seen this now working for a few minutes and a single test, but it *always* failed before so I'm now very hopeful that this bug is squashed for good. Thanks to all!
Thanks all for comments. I'll clone it for RHEL.
cronie-1.4.12-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
cronie-1.4.12-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.