Alternative to Crontab

[Kurt Wall]

On Sun, Nov 25, 2007 at 03:03:57PM -0800, jenix wrote:
> 
> "I give up....    You're still not answering questions."
> 
> Bruce, I appreciate the effort but you're going on about alot of stuff that
> seems irrelevant. What does the connection have to do with a running process
> on a linux box? The fact that the file is remote is irrelevant too. It could
> just as well be on the local machine. My question was simple; what
> alternatives are there to crontab? I'm no programmer and everyone here knows
> more than I do. Why make this so complicated? So I make the mistake of
> calling my web host an ISP. You asked, "whose machine would you LIKE to run
> a cron job". In the first and subsequent posts I said its on my ISP, aka
> "web host". 

First, to answer your specific question: "What are the alternatives to
cron?" The "at" program or some sort of script that wakes up every N
seconds, does something, and then goes back to sleep.

Not to be argumentative, but the fact that the file is remote seems 
pretty cogent to the discussion. The problem you're trying to solve
is sucking down a data file every sixty seconds without using cron to
do it. You're looking for an alternative to cron, sure, but you need
that alternative because you're trying to solve this other problem.
In any event, the cogency is just this: if the file is local, it's 
brain-dead easy to do. If the file is remote, it's only slightly less
brain-dead easy to do. If cron isn't an option, a script like this
should do:

while [ true ]
do
	scp remote.machine.name:/path/to/data/file .
done

You'd need SSH keys set up to make this work without a password, but
there are plenty of people here and elsewhere that would help you do
so.

Another alternative is to arrange to get the data file pushed to you
instead of you pulling it. That avoids your Web hosting provider's
monitoring entirely. All your Web host sees is an incoming file transfer,
but there will be no matching cron job in the logs, so, theoretically,
they shouldn't care.

On a more general level, you're dealing with engineers and techie gear 
heads here. We solve a problems by obtaining as much information about
the problem as possible and then proposing a solution. Actually, everyone
will contribute their suggestions until a solution emerges. Right now,
we're just trying to understand the problem.

Kurt