If you have a crontab job that runs every 5 minutes, how do you ensure that it won't ever overrun itself? That is, how do you make sure that the previous iteration of the crontab job completed before the next one runs?
at the beginning of your script, create a unique temp file somewhere in the file system, unless the file already exists, in which case your script is already running and you should exit. at the end of your script, delete the unique temp file.
there are other variations of this i'm sure, but they all have a similar idea. if you like this answer, please select the check mark next to it. thanks!
Use flock. It basically does what dqhendricks suggests.
Related
I'm not an advanced user of Linux, but I'm looking for some simple script in bash which will be working in cron or any other way and in 5-10 minutes period time will be looking for new files, after new directory/files are already uploaded to the directory script will move new directory with files to other location.
I found inotify which can be a great solution for this, but the issue is how to go with it.
I've been using inotifywait to recognize that some filesystem change ocurred in certain path.
Take a look at:
http://linux.die.net/man/1/inotifywait
You can specify on what changes you are interested (delete, create, modify, etc.) and whether the script should output it or simply exit after change.
I've been using this tool in a way that my script was starting inotifywait and when it exists, do some action and restart inotifywait again.
Hope this helps.
Martin
Trying to make a small script and cron job it in order to automate a task. Said script runs another script which has already been created, grabs the output, emails to specified recipients, and cleans up the output. I've got it almost down however am running into one major issue. The script that mine is running has a menu on the outset. That is to say, running the script by itself manually, i would have to select option 1 in order to get the output i want (the only other option, 2, is quit.)
How can I automatically enter (or simulate entering) the value 1 into the other script, so it does not hang when in a cron job waiting for user input?
Is there a sane way to do this?
Thanks in Advance.
You could try something as simple as using yes | command if answering yes is all that is needed. Otherwise you probably want to use expect to drive the imaginary keyboard for you.
http://expect.sourceforge.net/
Using autoexpect to record your session is a convenient way to come up with rough draft expect scripts as well.
My product requires a cronjob processing for every message a user sends to another users. This cronjob gets added to the crontab on the server. Everything works fine. Now once the job is done, is there a way to remove the expired cronjob entry from crontab?
Since the number of messages are huge, my crontab keeps growing so I want to clean up the old job entries. Any neat way of achieving it?
At least in most Linux distributions there is a crontab command that allows you to fetch and set the contents for the user's crontab. You can use it as such:
crontab -l > myfile
... edit the file (removing the entry)
crontab myfile
However this is clunky and error-prone. A better way is to wrap your job in a script that checks for a condition (e.g. a flag file) to decide whether to run the underlying logic and manipulate this flag file instead.
I have a crontab setup to run a perl script every hour, at 5 minutes past the hour (so 2:05, 3:05, 10:05, etc.):
5 * * * * perl /abs/path/to/my/script.pl >> /abs/path/two/my/script-log.txt 2>&1
As you can see, it's also redirecting both STDOUT and STDERR to the same log file.
I've been asked to refactor either the Perl script, the crontab entry, or to add any new code/scripts necessary so that every night, at midnight, the script-log.txt gets cleared/flushed/emptied.
That is, every night, at midnight, if script-log.txt has 20MB of text in it, to clean it out so that it now has nothing (0bytes) in it, and then at 12:05 AM the crontab would kick back in, run script.pl, and start adding more text to the same script-log.txt log file.
It would be enormously easier if there was a way to modify the crontab entry with some Linux/Perl magic to set up such a "daily rolling log file". In a worst-case scenario, we can always write a new script to purge script-log.txt and cron it to run at midnight. But my higher-ups would greatly prefer to not have yet-another cron job, and are looking for a way to do this from the entry itself (if possible).
In reality, we have dozens of entries that work like this, and so the problem with writing "purging script" and cronning it to run at midnight is that we'll constantly be updating the purging script as we add/delete other scripts that generate these kinds of log files. Thus, if we can set such purging up at the entry level, each cron entry cleans itself. Thanks for any insight/pointers/suggestions in advance.
You might want to look into logrotate.
Besides using top, is there a more precise way of identifying if the last executed command has finished if I had to check in a separate session over Putty?
pgrep
How about getting it to run another command immediately after that sets a flag.
$ do_command ; touch I_FINISHED
then when the command finishes it'll create a file called I_FINISHED that you
can look for.
or something more sophisticated that writes to a log file if you're doing it
multiple times.
I agree that it may be a faster option in the long run to have your program write to a log file or create a notification. Just put it at the end of the executed code, past the part that you suspect may cause it to hang.
ps -eo cmd
Lists all processes, and displays the command line, as 'typed' when the command started, so you will be able to tell your script apart from anything else running written in Perl.