Are you putting it into /etc/crontab by editing that file? or are you doing it with sudo crontab -e -u root to put it into the root users individual crontab file?
The syntax is different depending upon which file it is placed in.
The default /etc/crontab looks and is structured like this
# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
where ‘user-name’ is the name of the user to be used when running the command.
The individual crontab file is different in that it does not require the entries above the first command (though they are acceptable) and does not ever use the ‘user-name’ in that line. The individual crontab file is stored in a different location and is edited using the crontab command.
If you are putting the entry into a users individual crontab file then it only runs as that user by design.
Please show us which user is to run that task and the structure of the crontab entry as well showing which crontab file being used. The root user does not by default have an expiration on the account though other users may.
Never had any problems using this process on other Linux systems.
However, the other systems did have ROOT enabled.
The jobs are never run and the log files gives me the flowing output:
Nov 17 17:50:01 F36SE crond[34849]: (root) PAM ERROR (User account has expired)
Nov 17 17:50:01 F36SE crond[34849]: (root) FAILED to authorize user with PAM (User account has expired)
Nov 17 17:51:01 F36SE crond[34864]: (root) PAM ERROR (User account has expired)
Nov 17 17:51:01 F36SE crond[34864]: (root) FAILED to authorize user with PAM (User account has expired)
I’m guessing this is supposed to happen with ROOT disabled to enhance security.
However, I can’t run cron jobs in the background!
That looks pretty much what I’ve got.
I’m guessing the installer set this when ROOT user disable was set.
I’d rather not change this as who knows what else the installer did.
Thanks.
The root password does not normally expire, as noted with the 99999.
However, you are trying to run 2 different rkhunter jobs from the same crontab (not an issue) at the same time (potential issue). (file conflicts, race conditions, etc. are possible)
What happens if you alter the run times so one has additional time to complete before the other starts.
This way you could tell which task has a problem if it still occurs, and may be able to eliminate it entirely by avoiding one task conflicting with the other.
BTW, it is default for fedora to always have the root account locked when installed. This is security related, but does not interfere with tasks running as root.
I’ve been looking into other cron directories and a default daily script is included in /etc/cron.daily/rkhunter. I’ll delete all the old log files and see what happens in the next 24 hours…
Looks like the daily cron rkhunter job was run with the other daily jobs…
A new set of rkhunter logs were generated whilst cron was running…
This will do me. Thanks for your help guys!