Several server accounts where I run some scripts to extract data from databases have very limited tools available and on some of them you are not allowed (even by formal request) to use cron, than been said, can you recommend any tool(s) I can use to schedule the execution of the scripts (just like cron does)?

Thanks in advance :)

Update 1: Yes, the servers I am referring to are Linux, HP-Ux and Solaris, Bash > 3.x is available.

6 Answers 6


If you are allowed to SSH from a server with Cron, you could launch periodic jobs remotely.

  • 1
    Probably the best bet -- put a script on the target machine and execute it via cron/ssh <command>. Rolling your own scheduler (as per ktower) works but then the service won't resume after a reboot / no process management (assuming that if you can't use cron then you can't install an rc script).
    – Duane
    Commented Mar 11, 2010 at 14:32
  • @kmarsh I could do that from a local server yes but, sometimes I need to make 2 or 3 hops to reach the server that contains the required data using ssh or ssh plus tunnels. Maybe I need to investigate if one server before the server that has the data allows the usage of cron... thanks. @Duane these servers aren't rebooted very often still you are right I will need to document this somewhere and make everybody aware of it if I decide to use ktower's solution... thanks
    – alemani
    Commented Mar 11, 2010 at 21:30

How about a backgrounded, no-hup'd script in an endless loop with a sleep at the end?


$ cat runme.sh
while true; do
  echo "Do useful stuff here"
  sleep 86400
$ nohup ./runme.sh &

This would print "Do useful stuff here" once a day.

  • Until the next reboot, that is. Commented Mar 11, 2010 at 14:24
  • Indeed. The thing about workarounds is that they typically aren't a 100% solution.
    – ktower
    Commented Mar 11, 2010 at 14:33
  • thank you for your answer seems to be promising, still a 'workaround' but considering my actual situation I will give it a try
    – alemani
    Commented Mar 11, 2010 at 21:33

ktower's suggestion will work, and I can't think of a better way, but if you had a real choice it wouldn't be the solution you'd pick. The best suggestion I can make to to move it all over to a host that provides the tools and facilities you require. Workarounds will generally cause more problems than they solve. With such a large choice of hosting providers there really is no reason to settle for a makeshift solution.

  • Bingo. Even $5/month hosts offer cron these days.
    – ceejayoz
    Commented Mar 11, 2010 at 14:47
  • These servers aren't for hosting web pages, most of them are running Oracle DBMS and Tomcat and sadly we only have user accounts that are allowed to ran certain scripts and limited by the tools available, that's why I am looking for an alternative to Cron and yes ktower's suggestion looks promising. These machines are been administered on-site on each client infrastructure so there's no easy way to pick a new provider.
    – alemani
    Commented Mar 11, 2010 at 21:11

Are you able to use the at scheduler?


Adding to ktower answer. If you have to go that route and you need a more frequent interval (i.e. run something every 5 minutes) you will see some drift in time. To minimize that you can use a line like (assuming you are using linux)

sleep $((60 - `date +%s` % 60))

where '60' is the number of seconds you want to wait.

  • Yes on some of the servers Linux is running on other Solaris or HP-UX is, but bash still available on all of them. I am planning to run the scripts every month or so.
    – alemani
    Commented Mar 11, 2010 at 21:04

As John G. noted, the way to win this game is not to play; i.e. to run your jobs on servers that allow at/cron. Of the workarounds listed, the idea to run cron/Task Scheduler to fire SSH commands from a separate server is probably the best assuming you have SSH access. (I don't have enough rep to upvote yet). Of the others: at will typically be disabled with cron; and any admin restrictive enough to deny at/cron will be most unhappy with your attempts to circumvent policy by running your shell scripts in a loop...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .