Skip to end of metadata
Go to start of metadata

Contents

Introduction

Executing the same event periodically runs the risk that one instance might try to execute before a previous one has completed. The reasons this can happen are varied:

  • unintentional - a previous event is taking longer to complete than expected (e.g, contention for resources)
  • cutting it close - the period between each event launch approaches the time for the the event to complete
  • high availability / quick recovery - repeatedly retry an event to ensure that a service/resource is still running/available

Event

The goal is to avoid the command of an event (not the event itself) from executing more than once at a time. The assumption, here, is that firing off multiple instances of the event is not problematic, but in fact, required.

as_user=
host=<host>
command=flock -ne <lockfile> -c <command>
notify_email=
notify_subject=
notify_message=
when_month=*
when_day=*
when_hour=*
when_minute=*
when_dow=*

Notes:

  • the flock tool is used to "manage locks from shell scripts"
  • the -ne options mean to obtain an exclusive lock and immediately exit if it is not possible
  • the lock lasts the lifetime of the <command>
  • <lockfile> should be in a safe location to avoid conflicts and security problems
  • the recovery time (or retry interval) of this event is 1 minute

Conclusion

Whether flock is used or some other such tool, the above event will ensure that only one instance of <command> is running at any given time.

  • No labels