I have a problem with crontab, it does not execute my shell sript.
Crontab -l :
01 * * * * login sh ~/delete.sh
Normally every minute it should execute delete.sh, but it doesn't.
Nothing in syslog:
Jul 8 14:00:31 crontab[22307]: (login) LIST (login)
Jul 8 14:01:08 crontab[22581]: (login) BEGIN EDIT (login)
Jul 8 14:01:51 crontab[22581]: (login) REPLACE (login)
Jul 8 14:01:51 crontab[22581]: (login) END EDIT (login)
Jul 8 14:02:01 cron[15185]: (login) RELOAD (crontabs/login)
--> THAT'S ALL.
PS: I've tried running it as root and as the normal user, no luck in either case.
You're expecting this:
01 * * * * login sh ~/delete.sh
to run the command every minute. In fact, it only runs it at one minute past each hour.
Change it to this:
* * * * * login sh ~/delete.sh
To address issues raised in the comments:
Cron jobs run with a limited $PATH, but /bin is certain to be in that $PATH, so there's no need to replace sh by /bin/sh.
There's no need to invoke sh explicitly. Just make sure that ~/delete.sh has a proper shebang (#!/bin/sh or #!/bin/bash) and that it's executable (chmod +x ~/delete.sh), and you can invoke it directly.
I don't know why you have a login command. It doesn't make sense to try to log in from a cron job. In any case, login doesn't take a command as an argument.
If login is meant to be a user name rather than a command, keep in mind that there are two different syntaxes for crontab entries. In the normal syntax, each line consists of 5 fields specifying when the job runs, followed by the command and its arguments. A system crontab entry adds a user account name between the time specification and the command. man 5 crontab for details. In normal usage, you should use the normal user syntax and manage your crontab using the crontab command; don't edit /etc/crontab or files under /etc/cron.* unless you absolutely have to.
Related
I have a script say:
[operations#dojo 2018-02-23--18-10-53 ~ $] ls -l cc_snapshot.sh
-rwxr-xr-x 1 operations users 6006 Feb 23 15:02 cc_snapshot.sh
/etc/cron.allow
operations
crontab -l
*/3 * * * * operations /home/operations/cc_snapshot.sh arg1 arg2 >> /var/log/cc_snapshot.log
However nothing gets printed in the /var/log/cc_snapshot.log.
If I remove the operations user from the cron I do see errors in /var/log/cc_snapshot.log as the script is not supposed to be executed as root user.
Any advise as to what I might be wrong here?
Clearly a file permission issue. root is the supper user in Unix environment and it can execute any script in that system. Hence second error message is coming from your script but not from shell. You script don't want it to be run by root. Check the user account whether it has proper access to the file location and proper permission to execute the script. These are the very common issues in Unix environment. Also check whether your user id is added to proper group or not.
I am running SUSE Linux as a non-root user (getting root access also will not be a possibility). I would like to have a .sh script I created be run daily.
My crontab looks like:
0 0 * * * * /path/to/file.sh
I also have a line return after this as per many troubleshooting suggestions. My script deletes files older than 14 days. I also added a means to log output to check whether the script runs.
However, the job does not run automatically. I also am not able to check /var/log/messages for any notifications on whether cron can run or not.
What am I doing wrong? How can I check if cron itself is running/can run for my user? Do I have to supply cron with any paths or environment variables?
The correct approach to run your cron every midnight is:
00 00 * * * /bin/bash path/to/your/script.sh >> /path/to/log/file.log
This have been discussed several times in previous post. I followed given advise but it does not work for me. I have two scripts which are run by the cron service every minute. To my surprise, only one runs per minute( 1st in the list below), the other fails (2nd in list below). Most surprising, when run direct from the terminal, both scripts execute fine.
Cron setup :
*/1 * * * * /home/user/Desktop/scripts/generatepattern.sh
*/1 * * * * /home/user/Desktop/scripts/getnextfile.sh
File permissions are:
-rwxr--r-- 1 user user 522 Jul 25 16:18 generatepattern.sh
-rwxr--r-- 1 user user 312 Jul 25 23:02 getnextfile.sh
The code for the non-schedulable( not running in cron ) is :
#!/bin/bash
#Generate a file to be used for the search
cd /home/user/Desktop/scripts
no=`cat filecount.txt`
if test $no -lt 20
then
#echo "echo less"
#echo $no
expr `cat filecount.txt` + 1 >filecount.txt
fi
In the last line you wrote cat filecount.txt instead of cat /home/user/Desktop/scripts/filecount.txt
I discovered the main issue was that the new cron settings only get used when the vi editor gets closed. Changes have to be made on the editor and a :wq command issued so that the new settings get installed. Just issuing :w command does not work since no install happens(this was my mistake). I realised this after issuing :wq command on vi and the following output displayed :-
# crontab -e
crontab: installing new crontab
Thanks to all other suggestions made.
I define a job with crontab like this
0 2 * * * dbadmin . /home/dbadmin/back.sh
it is not root I want to run this .sh file with dbadmin user.
but when I checked it is not working.
in the log it gives this:
Feb 22 21:16:01 localhost crond[14634]: (*system*) BAD FILE MODE (/etc/crontab)
Feb 22 21:16:01 localhost crond[14634]: (dbadmin) RELOAD (cron/dbadmin)
Feb 22 21:16:01 localhost crond[28451]: (dbadmin) CMD (dbadmin . /home/dbadmin/back.sh)
How can I fix this? thanks in advance
Make a crontab entry as dbadmin without the username in it:
0 2 * * * /home/dbadmin/movefolder.sh > /home/dbadmin/cron.out 2>#1
Each day the logfile /home/dbadmin/cron.out should be replaced by a new one.
When you are confident about the cron+movefolder, replace the outputfile with /dev/null.
When above fails, check calling the script as dbadmin:
sh /home/dbadmin/movefolder.sh
When this one works and cron fails, it might be the environment. Try saomething like
0 2 * * * . /home/dbadmin/.profile; /home/dbadmin/movefolder.sh > /home/dbadmin/cron.out 2>#1
Using the crontab program, you normally have access only to the 5 scheduling fields (minute, hour, day of month, month and day of week). However, with Vixie cron (usually on Linux) by editing the system crontab file (/etc/crontab, as well as files in /etc/cron.d) you can use the 6th field for the username. For example, see How to specify in crontab by what user to run script?
If you use crontab to enter this line
0 2 * * * dbadmin . /home/dbadmin/back.sh
^^^^^^^
the "dbadmin" username is treated as the command to execute. You can (as noted in crontab's manual page) use that line in /etc/crontab. I pointed out that this is Vixie (also known as ISC) crontab. Legacy systems such as Solaris have a less capable crontab which would not allow specifying the user to run under.
According to cron's manual page, it will send output via email. Perhaps there was no email because the command "dbadmin" failed.
You need to use sh command for executing sh file.like following
0 2 * * * dbadmin sh /home/dbadmin/movefolder.sh
Hope it works.
Thank you.
I'm using a basic shell script to log the results of top, netstat, ps and free every minute.
This is the script:
/scripts/logtop:
TERM=vt100
export TERM
time=$(date)
min=${time:14:2}
top -b -n 1 > /var/log/systemCheckLogs/$min
netstat -an >> /var/log/systemCheckLogs/$min
ps aux >> /var/log/systemCheckLogs/$min
free >> /var/log/systemCheckLogs/$min
echo "Message Content: $min" | mail -s "Ran System Check script" email#domain.com
exit 0
When I run this script directly it works fine. It creates the files and puts them in /var/log/systemCheckLogs/ and then sends me an email.
I can't, however, get it to work when trying to get cron to do it every minute.
I tried putting it in /var/spool/cron/root like so:
* * * * * /scripts/logtop > /dev/null 2>&1
and it never executes
I also tried putting it in /var/spool/cron/myservername and also like so:
* * * * * /scripts/logtop > /dev/null 2>&1
it'll run every minute, but nothing gets created in systemCheckLogs.
Is there a reason it works when I run it but not when cron runs it?
Also, here's what the permissions look like:
-rwxrwxrwx 1 root root 326 Jul 21 01:53 logtop
drwxr-xr-x 2 root root 4096 Jul 21 01:51 systemCheckLogs
Normally crontabs are kept in "/var/spool/cron/crontabs/". Also, normally, you update it with the crontab command as this HUPs crond after you're done and it'll make sure the file gets in the correct place.
Are you using the crontab command to create the cron entry? crontab to import a file directly. crontab -e to edit the current crontab with $EDITOR.
All jobs run by cron need the interpreter listed at the top, so cron knows how to run them.
I can't tell if you just omitted that line or if it is not in your script.
For example,
#!/bin/bash
echo "Test cron jon"
When running from /var/spool/cron/root, it may be failing because cron is not configured to run for root. On linux, root cron jobs are typically run from /etc/crontab rather than from /var/spool/cron.
When running from /var/spool/cron/myservername, you probably have a permissions problem. Don't redirect the error to /dev/null -- capture them and examine.
Something else to be aware of, cron doesn't initialize the full run environment, which can sometimes mean you can run it just fine from a fully logged-in shell, but it doesn't behave the same from cron.
In the case of above, you don't have a "#!/bin/shell" up top in your script. If root is configured to use something like a regular bourne shell or cshell, the syntax you use to populate your variables will not work. This would explain why it would run, but not populate your files. So if you need it to be ksh, "#!/bin/ksh". It's generally best not to trust the environment to keep these things sane. If you need your profile run the do a ". ~/.profile" up front as well. Or a quick and dirty way to get your relatively full env is to do it from su as such "* * * * * su - root -c "/path/to/script" > /dev/null 2>&1
Just some things I've picked up over the years. You're definitely expecting a ksh based on your syntax, so you might want to be sure it's using it.
Thanks for the tips... used a little bit of each answer to get to the bottom of this.
I did have the interpreter at the top (wasn't shown here), but may have been wrong.
Am using #!/bin/bash now and that works.
Also had to tinker with the permissions of the directory the log files are being dumped in to get things working.