I'm trying to execute a shell script from cron on Freebsd.
To test whether crontab is working at all, I wrote the line
* * * * * echo "Hello" > /home/myuser/logile
and it work fine.
But when trying to execute any script it doesn't do anything, not even an error. (In the script I tried to run is just the same echo command)
Below is the output of crontab -l:
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
HOME=/home/myuser
MAILTO=myuser
* * * * * /home/myuser/shellscript.sh > /home/myuser/logfile
Why is the script not getting executed, although crontab is obviously running?
Permission for all files are set to rwxr-xr-x.
* * * * * /bin/sh /home/myuser/shellscript.sh
or
* * * * * /bin/bash /home/myuser/shellscript.sh
worked for me in Macosx 10.6 as rootuser
Have you checked that the command line has a linefeed/CR at the end of the line? I struggled for hours trying to find a reason for non-executing php script on cron when I simply hadn't pressed enter at the end of the line when I edited the cron jobs with crontab -e :-)
Have you checked /var/log/cron for clues?
Have you tried
* * * * * /bin/sh /home/myuser/shellscript.sh > /home/myuser/logfile
cron sends any errors via email to owner of the crontab file (often "root" so you might check that account's email). To have any errors mailed to "crontabOnFreebsd" put:
MAILTO=crontabOnFreebsd
in your crontab (near the top).
For more info issue this command:
man 5 crontab
If you are getting an error, then your logfile might not capture it, try this:
* * * * * /home/myuser/shellscript.sh > /home/myuser/logfile 2> /home/myuser/errorfile
Its been a while since I did any cron stuff; but things that always used to get me:
Environment variables not been set: generally I found it necessary to set up full paths (even to things like 'cat') to all commands [or at least set ENV variables within the script itself].
Ensure the user who owns the script etc is really the user which is running the script: this might not be the same user when you test from the interactive shell. Same goes for the directories/files that the script might write to.
Also: check the email for the root user - you might find that the errors have been diverted to the inbox, which may help you troubleshoot this further.
Related
I want to disable email reports on some tasks which run frequently. I've gone through the following links
https://unix.stackexchange.com/questions/84335/stop-cron-sending-mail-for-backup-script
https://www.cyberciti.biz/faq/disable-the-mail-alert-by-crontab-command/
They suggest adding >/dev/null 2>&1 at the end of the command to disable emails.
This is my crontab entry :
* * * * * /bin/bash /home/ubuntu/startup/monitor-mosquitto.sh >/dev/null 2>&1
But I'm still receiving emails every time the script is run. In fact, not just once but I get like 8-15 mails every time it runs.
Am I doing anything wrong here ? BTW, I'm using crontab as root ( sudo crontab -e )
See man 5 crontab:
If MAILTO is defined but empty (MAILTO=""), no mail will be sent.
If memory serves, I have used that on the line itself, or preceding it:
MAILTO=""
* * * * * /bin/bash /home/ubuntu/startup/monitor-mosquitto.sh
Note that this will affect all lines that follow it so you may want to place it last, or renable MAILTO.
Also, strictly speaking, you should be able to work out what you did with shell redirection in the shell itself. What you have looks correct so I am a little puzzled. Maybe make sure to test it as root not as you.
I have a bash script that I want to be executed every 15 minutes, so I added this line to my crontab:
7,22,37,52 * * * * /path/to/my/script.sh
I've checked the directory path to be correct and the script runs correctly if I just run /path/to/my/script.sh manually from any directory. I have this bang line in my script:
#!/usr/bin/env bash
My script also references other scripts in the same directory as it, and I have run chmod +x on all scripts that are needed. I set the MAILTO to my email address and I was getting some Cron Daemon emails when I changed the line in my crontab to:
7,22,37,52 * * * * sh /path/to/my/script.sh
But I never received emails upon using
7,22,37,52 * * * * /path/to/my/script.sh
or
7,22,37,52 * * * * bash /path/to/my/script.sh
I made sure cron is running and I've also tried redirecting the output of my script to a log file, which is also only written in when I include the sh. However, if I run sh /path/to/my/script.sh from the home directory, it does not work. The only ways my script actually runs is if (from any directory) I call /path/to/my/script.sh or bash /path/to/my/script.sh. I'm pretty new to writing bash scripts so any help is very welcome.
#pvas The cron user environment should be treated with extra special care. The assumption that most users have is that they will have access to paths, directories, permissions etc. This is far from the case. Cron runs in a minimal environment and you must set up EVERYTHING - Paths, Permissions and the location where the scripts are running from.
1) I set up the environment myself.
2) I use fully expanded paths in my crontabs.
3) I make sure any directories that need to be read have read permissions.
4) I make sure that my password does not expire because that will block cron when it does.
5) Make sure underlying scripts are explicitly invoked (by Perl, Bash, Python whatever).
6) Pipe the command on the cron line to a LOG file (even better a log file with a TIMESTAMP).
Fix these things and then try again. Cron is particular, you need to set up everything.
For example:
#SETUP ENVIRONMENT
SHELL=/bin/bash
source /home/userfoo/.bash_profile
#RUN THE SCRIPT everyday at 11:50pm (23:50)
50 23 * * * userfoo /home/userfoo/script.sh >> LOGFILE.txt
<<
Crontab entries should have the following format
m h dom mon dow command
which confirms that your entry below
7,22,37,52 * * * * /path/to/my/script.sh
is correct. Having said that, you must close the crontab editor(:wq) for the changes to come to effect.
It is suggested you go through [ this ] cross site post which portrays the possible issues with cron jobs.
More about hashbang [ here ].
I have a script to backup my database at /home/<user>/bin/dbbackup. The script is executable by all users, and owned by me. The files /etc/cron.allow and /etc/cron.deny do not exist.
In my crontab I have the following lines (including a new blank line after the last line of code):
#reboot /home/<user>/.dropbox-dist/dropboxd
30 2 * * * bash /home/<user>/bin/dbbackup
However, cron is not running my dbbackup script. When I run a manual test of the script it works. When I run this test on the command line: * * * * * /bin/echo "cron works" >> ~/file I get the following error:
No command 'dbbackup' found, did you mean:
Command 'dvbackup' from package 'dvbackup' (universe)
Command 'tdbbackup' from package 'tdb-tools' (main)
dbbackup: command not found
My server is running Ubuntu Trusty. Any help please?
As the comments noted, it appears that amiga_os needed remove the reference to bash in the line.
30 2 * * * bash /home/<user>/bin/dbbackup
Should be.
30 2 * * * /home/<user>/bin/dbbackup
I usually just call scripts from their path and use "#!/bin/bash" (or wherever your bash lives) as the first line of the script. It appears the amiga_os had already done this, which is good. I don't like putting sentences into cron because it makes me nervous.
I think it was a path issue as cron executes as the user but does not read the bash profile and therefore does not work exactly like it would under your shell as it might not have access to your $PATH.
I have added a script in crontab for every 30 minutes. The line goes as follows:
*/30 * * * * root perl /root/perl.pl
The above script has a execution of system command 'top' and it gets printed in a log file.
If I run it manually it runs fine. But while running it via crontab, it does not show up the desired results. Please can somebody help me with this. Thank you.
The command in the above perl script is:
$top = `sudo top`;
The error I am getting is:
sudo: sorry, you must have a tty to run sudo
I changed my command from sudo to visudo. But still the problem remains.
You should use the full path in cron (and use which perl to find the full path):
*/30 * * * * root /usr/bin/perl /root/perl.pl
OR better yet, make the script executable using chmod +x, and add the interpreter to the beginning of the script #!/usr/bin/perl -w and call it directly from cron
*/30 * * * * root /root/perl.pl
Also if there is a problem in the perl script, you could output the result from cron like this
*/30 * * * * root /root/perl.pl > /tmp/myscript.log
You should look into the requiretty setting with regard to visudo. Look for a line that reads Defaults requiretty. You could try commenting it out, but you will be sacrificing some security. See man sudoers.
You could also try running top in batch mode with one iteration:
$top = `sudo top -bn1`;
Batch mode option is for sending output to other programs.
When I run a script manually using root it is working fine. when I execute the same script inside cron it is not running. I checked the cron is actually calling the script but the script is not executing. I exported the output of echos in the script to the text file but the text file is didn't logged anything. Please check this cron
*/10 * * * * sh /var/www/sym_monitor/restart.sh > /var/www/migrate/root_restart.txt
Another approach to avoid typing full executable paths is to put shell global variables at the top of your crontab :
SHELL=/bin/sh
PATH=/bin:/usr/bin:/usr/local/bin
MAIL=me#domain.tld
*/10 * * * * stuff > log 2>&1
Note the > log 2>&1 syntax to log both STDERR & STDOUT in log file
Try changing sh for /bin/sh.
*/10 * * * * /bin/sh /var/www/sym_monitor/restart.sh > /var/www/migrate/root_restart.txt