SMSD retry backoff on full dispatch failure (specification)
Introduction
When all dispatchers fail to dispatch an SMS, smsd will retry at the next queue read (which implies a 30 second delay, using default values). A total dispatch failure is a CRITICAL level error, and the loghandler will notify the NAV admin via e-mail.
A long-lasting error state will result in a lot of e-mail spam for the administrator. This should be mitigated by introducing a backoff mechanism for retries.
Requirements
For each completely failed dispatch attempt, the retry delay will increase by a factor X.
If Y>0, once Y repeated dispatch attempts have been unsuccessful, smsd must choose one of the following scenarios:
If Z is disabled, all queued messages must be marked with status=ignored. A CRITICAL error must be logged, containing details of all the ignored messages. SMSD must then resume its normal queue-checking loop.
If Z is enabled, a CRITICAL error must be logged. The error message must contain the number of unsent messages, and the age of the oldest mesasge. The daemon process must then shut down.
If Y=0, the daemon must continue its dispatch attempts indefinitely.
Once the loop delay reaches the value M, exactly _one_ CRITICAL error must be logged, containing the number of unsent messages and the age of the oldest message. The error message must specify that the daemon will continue to retry dispatch. The loop delay must never increase above M.
Values M, X, Y and Z must be configurable in smsd.conf