Visit Our Home Page
 Explored,Designed,Delivered.sm
Welcome, Guest. Please Login or Register (Password Reminder)


Creativyst Forums 
Support & Discussion 
Register Help Search Login  
   
   Creativyst Forums-TOP
   Web Site Design
   Can you run crontab FROM cron?  Yes
(Moderator: admin)
 Author
Topic: Can you run crontab FROM cron?  Yes       [Link=43]
Reply Please log in first.
JRepici
Administrator


Posts: 328





Gender:
      JohnRHere2
    Can you run crontab FROM cron?  Yes   (Date posted: 02/02/03 at 15:02:11) Quote Modify Delete

Report

Well, there seems to be no problem at all with changing your crontab {file} from the cron daemon.

I've tripped over a few pitfalls while producing a little script to dynamically change my local cronjobs text and then get it into the system cron table. I'll report on them here.

. . . . . . .
Background

I wanted to password protect the entire statistics area of this site but show a couple of the graphics from that area on a publicly viewable site statistics page where there are no access restrictions.

To do this I needed a cron to copy the three files involved which (today) are

  • .../www2003/graph2003.gif
  • .../www2003/stats0103.gif
  • .../www2003/avday0103.gif

The trouble with this is that these paths and files, while updated daily, have names that change based on the year and month (tomorrow, two of them will change from "0103" to "0203"). So I also needed cron to run a script that changes the cp commands in my local crontab file.

Lastly, and this is the part I was concerned about, I needed to automatically add these changes to the system cron table. To do that the cron daemon has to do a 'crontab {myLocalCronFile}', changing the very table it was working from at the time it was working from it. Should have known though, those Linux heads would be very good about the subtle intricacies of things like this. It worked fine.

. . . . . . .
I did make some dumb mistakes though. So in the interest of full-disclosure...

. . . . . . .
To Do or Not

Firstly, always turn on MAILTO whenever you're adding new things to cron. MAILTO=me @ mydomain.com for example. For me, this has been invaluable in pointing up all the dumb little coding mistakes I thought I had fixed.

Always use absolute path names. This is pretty clear in the man pages, but if you're used to doing relative paths you may miss a few. For example, I like to use relative paths to my library functions when including them in perl scripts:


Require("../../mylib.pl");

Even though I knew this script would be run with a fully qualified path from a different directory, I typed in a relative path name out of habit. It didn't turn up when testing the script, because when testing I ran it from the local directory where it was stored. Thanks to MAILTO though, this came to my attention on the first of the month when the cron daemon ran the script.

It may actually be worth it to test the script by running it using a qualified path from a different directory (cwd). This would more closely simulate how your script will be run when the cron daemon does it.

Final test from cron. We all know this. It isn't rocket science. It's simple vocational discipline. Test in conditions that most closely mimic run-time conditions. You've tested it by invoking it manually. You've tested it by invoking it from another directory. Why not test it by actually dropping it in the cron table to run a minute or two from now and watching cron run it?

. . . . . . .
HTH

       -John




. . . . . . . . . . .
P.S. Well, there are a million ways to do any one thing including this. Another forum member asked me:

"Why don't you just run a dynamic script that does the copies and let the script deal with the changes in filenames when necessary?"

Well, du? Had I done it that way I would have alleviated the necessity to update the system cron table from cron.

In fairness to the solution presented here though, my vocation (software designer) teaches me to always pull the processing overhead out of the part of the loop that runs most often.

In this case, having cron update itself once a month instead of running the script every night reduces the processing overhead by a factor of thirty (from once a day, to once a month). That makes the above solution superior in theory.

There's an old quote that says: "In theory, there is no difference between theory and practice, in practice, there is". Translation? In the real world, it's just not that big a deal to run a script once a day instead of once a month. However, if you have this cavalier attitude with hundreds or thousands of scripts the situation starts changing.

Also, running a script that runs the copy commands would have required system() calls from inside the script to run the copy commands, something that security conscious people don't like one bit.

Lastly, had I run the copies from a script every night I would never have learned that you can update your system cron tables from within a cron job.

Last modification: JRepici - 02/02/03 at 15:02:11

   E-Mail   Ip: Logged
Reply Please log in first.
Pages: 1
Jump to:

YaBB Board c 2000
YaBB Programming Team
 



















© Copyright 2002 - 2008 Creativyst, Inc.