Today I ran into a problem at work that I thought would be worth sharing. It is one of those odd only-happens-once-in-a-blue-moon errors, so writing it down and putting it out there on the internet may help those lucky few who run into it.
I had a report from a user that the system account he and his team share was unable to run cron jobs. My initial checklist of things to verify were:
- Verify the syntax of the cronjob(s) by viewing the crontab: crontab -u <username> -l
- Verify user was listed in /etc/cron.allow, or *not* listed in /etc/cron.deny.
- Check the /var/log/cron for informational messages.
The cron syntax looked fine–I didn’t see any errors. I also verified that they were listed in the cron.allow file. (Our systems implement a cron.allow policy, for security.). From the crontab man page:
If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command.
It was the third entry, the system log, that alerted me to the problem.
Jan 5 10:26:01 hostname crond: User account has expired
Jan 5 10:26:01 hostname crond: CRON (username) ERROR: failed to open PAM security session: Success
Jan 5 10:26:01 hostname crond: CRON (username) ERROR: cannot set security context
The key piece of information here is “User account has expired.” While the shared system account was still usable–it doesn’t require a password–it had technically expired which meant cron would restrict its jobs. Remember, 99% of the time the system log tells you exactly what the problem is. The key is reading!
The solution was to unexpire the system account. To do so you can use the chage command or the passwd command. In this situation, because this is a shared system account that does not need to expire, I set it to never expire:
passwd -x -1 username
From the passwd man page:
This will set the maximum password lifetime, in days, if the user’s account supports password lifetimes. Available to root only. This will set the maximum password lifetime, in days, if the user’s account supports password lifetimes. Available to root only.
As you might guess, -1 sets an infinite value meaning it will never expire.