29 August 2010

Bash : My recent lessons from mistakes


I was trying to run some scheduled jobs using "at"
Things seemed to work but they didn't really work.
I figured out that some needed programs/functions were not available when the at job was running. Why? Well, interactive shell loads lots of stuff that may not be loaded when an at/cron job runs on its own.

Tips:

"source file"  is an alias for ". file" and may not be available on the workspace at is running the job on. Better use ". file" to load functions from a file. You can see all the alias/functions available in your session with the command "set"

Since you don't see the output of at jobs, it is recommended you redirect both outputs for troubleshooting/verification (always specify full path to the files, you don't know where at will run the job from)

There are many ways:

command  >  out.log 2> error.log
command  >  out.plus.error.log  2>&1 

See more on http://www.linuxtutorialblog.com/post/tutorial-the-best-tips-tricks-for-bash

If the job is complex, you may require timestamps in the output (this is mixing both outputs and adding the timestamp)

command   2>&1  | sed "s/^/\[`/bin/date +%F`\] /"  >> all.with.timestamp.log


Since you know where the job is going to run, you can monitor what it does with some sort of

watch -d '/bin/ps auxww | grep <your_username> '

And also checking how the logs are moving

tail -f  /location/logs/*


If you read that "at" is not for periodic jobs, ignore that. If you want to run the job periodically, just add at the end of the job a line scheduling the job again. In this way, you schedule it one time, and it will schedule itself from then on. You can always stop this with "atrm"


Kind regards / Atentamente
Ruben

0 Comments:

Post a Comment

<< Home

Too Cool for Internet Explorer