overlapping cron job?

[JMaster]

I'm writing an hourly cron job that is sending files to a remote server via FTP. Problem is, some of these files may take over an hour to send, so I don't want the cron job to be run if an instance of itself is already running. Is this possible to check?

 

[jfall]

You'd have to put the checking within the script your running

 

[JMaster]

Originally posted by: jfall
You'd have to put the checking within the script your running

Any idea how?

 

[akubi]

uh a trivial solution would be to touch a file in /tmp at the beginning of the script and remove it when it's done. only execute the ftp logic if the temp file is not there.
of course it has it's holes but if you want something quick and painless...

you can also grep for your script in ps

 

[JMaster]

Originally posted by: akubi
you can also grep for your script in ps

that's what I was thinking, but is there a way to specify which process is the current cron job?

 

[Nothinman]

The flag file is probably the better solution, parsing ps output can be really ugly.

 

[juiio]

Here is something you can use...

homedir="/home/whatever"

processpid=`cat $homedir/process.pid`

cd $homedir

if [ "$(ps x|grep $processpid|grep -v grep)" = "" ]; then

DO COMMAND HERE
echo $! > $homedir/process.pid

fi

 

[Nothinman]

Seems easier to understand to me...

 

[TerryMathews]

If it were me, I'd do something like this:

if[-x /tmp/ftp.lock]
else
{touch /tmp/ftp.lock
*script goes here*
rm /tmp/ftp.lock}

 

[TGS]

We use the "lock" file methodolgy in our scripts. More or less the same thing between nothin and terrys options. Easier to explain to other people what the purpose is, and self-explanitory for people looking at the file.

 

[Armitage]

Originally posted by: TGS
We use the "lock" file methodolgy in our scripts. More or less the same thing between nothin and terrys options. Easier to explain to other people what the purpose is, and self-explanitory for people looking at the file.

:thumbsup:
In fact, all the hard stuff is already done for you: man lockfile

 

[AgaBoogaBoo]

I agree with the flag file method.

 

[TerryMathews]

Originally posted by: TGS
We use the "lock" file methodolgy in our scripts. More or less the same thing between nothin and terrys options. Easier to explain to other people what the purpose is, and self-explanitory for people looking at the file.

Bingo, only reason I prefer to write my own is sometimes I'm on systems where lockfile isn't installed/ported and it's just easier to write it out.

Plus, after the second or third it becomes second nature.

 

[juiio]

Originally posted by: Nothinman
Seems easier to understand to me...

Unless your process dies unexpectedly without deleting the file...

 

[Armitage]

Originally posted by: TerryMathews

Originally posted by: TGS
We use the "lock" file methodolgy in our scripts. More or less the same thing between nothin and terrys options. Easier to explain to other people what the purpose is, and self-explanitory for people looking at the file.

Bingo, only reason I prefer to write my own is sometimes I'm on systems where lockfile isn't installed/ported and it's just easier to write it out.

Plus, after the second or third it becomes second nature.

The hand-rolled solutions have a potential race condition - if a second process checks for the lock after the first process checks, but before the first process creates the file, you'll end up with problems.

I've always assumed that lockfile handles this somehow. Or am I just delusional? In any case, it has some other nice features like retries, forcing removal after some specified time, etc.

 

[Nothinman]

Unless your process dies unexpectedly without deleting the file...

True, but that probably indicates bigger issues that will require manual intervention anyway.

The hand-rolled solutions have a potential race condition - if a second process checks for the lock after the first process checks, but before the first process creates the file, you'll end up with problems.

Unless cron freaks out that won't be possible since the job is hourly.

 

[Armitage]

Originally posted by: Nothinman

Unless your process dies unexpectedly without deleting the file...

True, but that probably indicates bigger issues that will require manual intervention anyway.

The hand-rolled solutions have a potential race condition - if a second process checks for the lock after the first process checks, but before the first process creates the file, you'll end up with problems.

Unless cron freaks out that won't be possible since the job is hourly.

Yep - for this particular case. And in fact anything kicked off by cron since it only checks every minute. Unless you maliciously schedule the jobs simultaneously :evil:

I use it for some other stuff that can be launched at random intervals - so it's possible, but very unlikely.