#321 closed defect (fixed)
xblade14: user cronjobs fail
| Reported by: | neteler | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | SysAdmin | Keywords: | cron xblade14 |
| Cc: | hamish |
Description
Hi SAC,
I have tried to restore my cronjobs (GRASS Web update etc) on xblade14. While crontab -l lists them, they are not executed.
Any ideas? Is there a magic setting to activate cronjobs at user level?
thanks Markus
Change History (5)
comment:1 by , 16 years ago
| Keywords: | cron xblade14 added |
|---|---|
| Owner: | changed from to |
| Type: | task → defect |
comment:2 by , 16 years ago
| Status: | new → assigned |
|---|
My preliminary assumption is that this relates to the funny way I re-created the accounts, by just pasting the old entries in /etc/passwd, /etc/shadow, /etc/group and /etc/sudoers. However that does not explain why the problem occurs for LDAP related accounts like mine and Markus'.
Actually, this raises a second theory, that it relates to LDAP accounts not being properly enabled.
comment:3 by , 16 years ago
cron seems to be working for local accounts (tested with hobu2 account) so the issue appears to relate to ldap accounts only.
comment:4 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
I found messages in /var/log/cron indicating that the jobs were ignored because there was no passwd entry. A review of /var/log/cron on xblade13 showed things ok there, and some pam_ldap related messages. A reboot of xblade14 seems to have resolved the problem.
It appears that starting ldap service after crond started in the last boot meant that crond didn't know about ldap accounts.
comment:5 by , 16 years ago
I confirm that my cronjobs are back. Thanks.
Have also activated to start httpd after reboot.
I have confirmed this problem. I'm digging into it, but anyone else with ideas is encouraged to follow the ticket.