cancel
Showing results for 
Search instead for 
Did you mean: 

Using any shell command in CRON

Using any shell command in CRON

Using any shell command in CRON

Extracted from a post in Community by xpcomputers:
Most shell commands can be run, but need to have the full path to make them work.
eg. tar becomes /bin/tar in CRON
But how do you find out that full path of your command?
If you run a CRON command of:



whereis tar > httpdocs/tar-loc-log 2>&1



This will output the location of the tar command into a logfile called "tar-loc-log" in your httpdocs directory.
The first bit of that logfile says:
/bin/tar
so we know that is the path to use the command in CRON.
Another example to find the path of the useful shell command "env":
Code:


whereis env > httpdocs/env-loc-file 2>&1


.....which gives the path of "env" (environment discovery command). The first path listed is /usr/bin/env
So lets use that "env" command and it's path we just discovered:
Code:


/usr/bin/env > httpdocs/cron-env-log 2>&1


This will put in the cron-env-log file various facts about our CRON environment. A crucial bit here is PWD - (which means Print Working Directory), which prints the working directory that CRON operates its commands from. Mine is the root of username.plushost.co.uk, but those with their own domain might see something different so run the command to see your PWD.
This tells us that all commands we use must use either a relative path to that PWD or we must use an absolute path.
To use a relative path, you leave off the leading "/" like we have in the location of the logfiles we are creating in the httpdocs directory (which is underneath the root of the working directory):
eg. httpdocs/cron-env-log references the path username.plushost.co.uk/httpdocs/cron-env-log
To use an absolute path you include the leading "/"
eg. /usr/bin/env references the path to the env command which is completely outside the username.plushost.co.uk directory
Logfile notes:
You can run any of these tasks without the logfile creation, but you will be running blind, so there is no point in my opinion.
I recommend using a different log file for each job. Just create a unique log file name for each CRON task (with something meaningful) to identify the right log in the httpdocs directory.
If you have an error in your log, I recommend either deleting the log file before running the amended task again, or giving the logfile an incremented name eg. tar-gz-log becomes tar-gz-log2.
This way you will know if the output is the same, or if your task just hasn't run the second time! This could save you headaches in thinking you have tried a combination that would have worked.
(If you really don't want to run with a logfile, just delete everything from the first ">" onwards.)
If you want the job to run multiple times and append on to the end of the existing logfile each time, then replace the first ">" with a double one ">>". This should add the info to the bottom of the existing file.
Timing the CRON task:
Set the time to be a suitable interval in the future. How close you can get will depend how accurate your computers own clock is to help you predict the time on the server. To start with allow at least 5 minutes or more maybe (or start lower and work up until it works). Allow a suitable time for the task to have run before checking the results!
I recommend filling in all the entries, including day of the week, as a mishap precaution. Although you could save a few seconds by using an * to mean any day, any month, etc etc, if you forget to delete the CRON task, you might find your CMS or whatever gets overwritten, tomorrow, next week, next month, or even next year. By having the day of week and all other info in the task, it will be currently 6 years until that day of the week is the same date again... and by then you will probably be using a completely different CMS package and even a completely different webserver!
Don't forget to delete the task afterwards:
By using a fully specific set of date & time information, you have made it so your task will only run every 5-6 years (depending on leap years) as a safety measure. However, you really don't want to forget to delete your task once it has run, as you might get a shock in the future! This is even more true if you get lazy and use * instead of specific dates. You have been warned!
Go and use your knowledge:
Now armed with those generic instructions, you should be able to use almost any shell command you need from a CRON task (within reason), or even any script:
Reminder:-

  • Do a whereis to find the full path of your command
  • Always use the full path of the command
  • The command will execute from within the Working Directory, so use relative & absolute paths accordingly
  • Use a logfile to "see" the result & any error messages
  • You don't have write permissions for the working directory (hence the use of httpdocs/ for the log files and for the output of for example tar unpacking)
  • Use specific date & day in scheduling task (for safety)
  • Check the logfile for the info output (& any errors)
  • Delete the task when you know it has worked!

Now go and have fun!
0 Thanks
0 Comments
368 Views