Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#321 closed defect (fixed)

xblade14: user cronjobs fail

Reported by: neteler Owned by: warmerdam
Priority: major Milestone:
Component: Systems Admin Keywords: cron xblade14
Cc: hamish



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 Changed 10 years ago by warmerdam

Keywords: cron xblade14 added
Owner: changed from sac@… to warmerdam
Type: taskdefect

I have confirmed this problem. I'm digging into it, but anyone else with ideas is encouraged to follow the ticket.

comment:2 Changed 10 years ago by warmerdam

Status: newassigned

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 Changed 10 years ago by warmerdam

cron seems to be working for local accounts (tested with hobu2 account) so the issue appears to relate to ldap accounts only.

comment:4 Changed 10 years ago by warmerdam

Resolution: fixed
Status: assignedclosed

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 Changed 10 years ago by neteler

I confirm that my cronjobs are back. Thanks.

Have also activated to start httpd after reboot.

Note: See TracTickets for help on using tickets.