F20 Where's my system mail?

Fred Smith fredex at fcshome.stoneham.ma.us
Mon Apr 14 13:10:52 UTC 2014


On Mon, Apr 14, 2014 at 09:20:09AM +0100, Arthur Dent wrote:
<snip>
> The test example I gave yesterday is in fact based on a real-life case.
> I have a job that runs hourly from cron. Occasionally this process fails
> (for reasons I won't bore the list with) and leaves a lock-file in place
> - a will then refuse to run again until someone (me) has cleaned up
> after it. The only way I even know that this has happened is accuse I
> have another little hourly cron job that checks for the presence of the
> lock-file and reports only if it exists.
> 
> If I have to rely on the daily logwatch output it could conceivably be
> up to 23 hours before I even know that the job is not working...

I've used, in the past, a mechanism where the program controls its own
lock file, so it has control over what goes inside the file. (I dunno if
your app is simlar, or if it uses some system services to manage lockfiles.)

When starting up:
1. see if the lockfile exists
1a. Exists: open it, read its contents, which should be the PID of the
    program that created it. see if a process of that PID is still running. 
    If so, silently exit. if the pid doesn't exist, delete the lock file
    and go to step 2.
1b. if no lockfile, start normally.
2. normal start: create the lockfile, write your own PID into it.
3. program runs.
4. when program finishes, it removes the lockfile.

This lets the program determine, whenever it starts up, if it's a bogus lock
file, or if it isn't. If it no longer refers to a running process, it can
simply be deleted without causing any undue delays.

-- 
---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
                        The Lord is like a strong tower. 
             Those who do what is right can run to him for safety.
--------------------------- Proverbs 18:10 (niv) -----------------------------


More information about the users mailing list