I have a perl script which accepts a file as input and ftp the file to a particular sever.I scehduled this script at a specific time using crontab.Everything seeems fine if the input file is available under the path.
Now assume due to some reasons the input file is not avaialble by the time the script is scheduled.So obviously the script will fail.
My requirement is, if the input file is not available then reschedule the script after 30 minutes.I tried to implement this logic using 'at' command by including the below statement in the script :
As i expected the script is rescheduled after 30 minutes,but by the time it is running, the script is parsed or interpreted using 'sh' and not with 'perl'. The shebang line #!/usr/bin/perl is already there in the script.I don't know why it is not picking up the shebang.The error is like this:
sh: line 35: use: command not found
sh: line 36: use: command not found
(throwing error at the 'use' line which is used to include module in perl, and the error is running long in all the perl specific commands)
Can anybody suggests how to make invoke this rescheduling with the perl intrepreter.I checked the man pages of 'at', but no info regarding this.Environment details are as below:
Perl version: 5.8.3
OS: Linux Ubuntu 2.6.15 i686
at version 3.1.9
The -f flag to 'at' is to specify a list of commands to be run, you're passing your perl script as if it should be executed in shell, line by line.
You want to provide the perl script itself as the command to execute.
[edit] To pass it on the commandline, echo the job into at and leave out the -f flag:
echo '/home/dileepp/scripts/ftp_file.pl 1> /home/dileepp/logs/ftp_file.log 2> /home/dileepp/logs/ftp_file.log' | at now + 30 minutes
Note that the 'now + 30 minutes' thing doesn't work on my version of at but you still should be ok with this syntax
If it were me doing this script though, I'd probably have it go to sleep for 1800 seconds instead of using at like this, but I suspect it's just a matter of preferance
fine.But my question is if i go with your way of letting the script sleep for 1800 seconds, the entire code remains in memory for 30 minutes,right?
But if i reschedule it the memory will be free for 30 minutes.
Since the server is supposed to run a lot of cron jobs may be simultaneously,is better to think from memory perspective.
Please correct me if am wrong,because am not an expert in this!
It's an interesting and valid point, as it's an interpreted script, you'd have the perl engine + any variables etc declared sitting about in memory wheras an 'at' invocation would clear out and leave the memory free until it's needed. I'm of the same school of thought that if we don't need to use RAM, we shouldn't.
But, there are some things to consider:
Your average perl binary is pretty small as far as memory footprints go
Modern unix systems typically don't have the kind of memory issues we used to have, physical chip ram is still precious but swap space on disk is usually rather copious.
CPU time is still precious, to start a new perl interpreter up is considerably more expensive on CPU than just running a sleep (to all intents and purposes, 0% cpu used) for 30 mins.
The operational risk _could_ be greater using 'at', this really depends on how the job works though. If you run this thing and it's waiting on some condition to complete before it carries on, could someone make the mistake of seeing it's finished running and thinking that means it's done? They might either run it again (resulting in two 'at' jobs scheduled) or assume it's fully complete.
Excellent.What you have explained is all perfectly correct and acceptable.
But in my case,am doing this operation in a development server(and is a temporary operation too).
This development server got a very little RAM and some cronjobs will take around 4-5 hrs to complete execution,but not doing big tasks.So issues with RAM is an important concern for me.
And two 'at' command execution is a possibility and the pass-through for this is already implemented in my program.The conditional block which holds this 'at' command execution statement will fire only if the program is invoked at a particular time,ie 23:45 for eg.
So after the first scheduling time in crontab (23:45),this conditional block will never fire the next time when it is executed with 'at' or manually.
Anyway, putting the ideas and suggestions like this is great because sometimes programmers never look into these areas,but only from a functional perspective.
