my user is not enabled to crontab but the scripts are working correctly, why? I have a redhat enterprise version 5.11. Where it goes to read the user's crontab configuration as the /etc/cron.allow file is empty.
Thank you
Greetings.
could be any number of things ...
- have you asked colleagues/sysadmins ....
- what did you use to confirm you are not cron enabled ...
- another user is running them
- add some debugging (create a temporary directory with world write access) and print some relevant (like which user , datetime stamps ...) information to a log file.
- change permission on your scripts so only you can read/execute them
- rename/move them and see if anyone raises an issue ....
.....
Yes, but, files cron.allow and cron.deny (which you can Google search for) control whether a user can submit new jobs, edit jobs, and delete jobs. If jobs are already established and cron'd before you edit that file(s), then they don't need further access to crontab for those jobs to run.
Cron jobs scheduled are stored/configured in a directory which can vary between different Unix/Linux distributions but generally are located somewhere like '/usr/spool/cron/crontabs'. In a directory somewhere like that you will find one file for every different username that has jobs scheduled. This is what the cron daemon reads into memory at boot time to know what to run. If you are sysadmin, you could (with care) edit crontabs directly and force changes but remember to restart the cron daemon afterwards to force the re-read of the schedules into memory otherwise nothing will change.
So you could take a look around and find the actual crontab directory where the schedules are stored. You can also look at the last modified dates to see when they were last changed.
1 Like
Have you tried basic cron "debug":
# edit current user crontab file, no need to know where it is:
crontab -e
# line - execute every minute:
# check where is your date
* * * * * /usr/bin/date > /tmp/mycrontst.log 2> /tmp/mycrontst.err
# list current user current crontab
crontab -l
# crontab -e = edit and reload rules for cron daemon = no need restart cron daemon
# look those /tmp files.
What do you have tried?
It's "normal" that your script works from commandline, but not from cron.
Why?
Cron env is not same as your env when you login.
Run command env and then look what cron tell about your environment:
* * * * * /usr/bin/env > /tmp/mycronenv.log 2> /tmp/mycronenv.err
=> script have to include to set environment, min. = check PATH variable if not use absolut path.
if not authorised to use cron then crontab -e command is unlikely to work
crontab -e wiht some basic command is a method to test, have user authorised to use cron without knowledge to look deeply cron setup. The original question give feelings that reason could be not allowed or ex. environment problem or ... That's why we need know more data to help. If my crontab ex. not work, then it's easiest is to ask helps from sysadmin. If my debug example works, but your script not, then show the script for us.
did you read the user's post .... and my initial reply ...
my user is not enabled to crontab but
- so it is reasonable to assume they've done the basics.
could be any number of things ...
- have you asked colleagues/sysadmins ....
- what did you use to confirm you are not cron enabled ...
- another user is running them
- add some debugging (create a temporary directory with world write access) and print some relevant (like which user , datetime stamps ...) information to a log file.
- change permission on your scripts so only you can read/execute them
- rename/move them and see if anyone raises an issue ....
.....
and @hicksd8 questions/response ....
you are adding entropy not help
1 Like
I think that explanation is true.
The crontab command works with cron.allow but the cron(d) scheduler works with PAM.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.