Scheduling executions of the start method of a periodic service instance (specified by the exec attribute of the periodic_method element) always requires the value of the period attribute of the periodic_method element. Other attributes of the periodic_method element might also be used, and the next_run value might be used.
The scheduling attributes of the periodic_method element (period, delay, jitter, persistent, and recover) are stored as properties of the periodic property group. For example, the period attribute in the manifest becomes the periodic/period property when the periodic service is imported. Administrators can use the svcpropand svccfg commands to view property values in the periodic property group and can use the svccfg command to modify these values.
The period property must have a valid value. The jitter, delay, persistent, and recover properties have default values and are not required to be explicitly set. The units for a time value are seconds, as shown in Figure 2, Table 2, Service Property Type Value Descriptions.
In the following scheduling descriptions, italic type indicates the value of the property. For example, jitter is the value of the periodic/jitter property in the service configuration repository, which is the same as the value of the jitter attribute of the periodic_method element in the service manifest.
When a periodic service instance is initially enabled (for example at system boot), the first execution of the start method of the instance occurs at the following number of seconds after the instance transitions to the online state:
delay + RAND(jitter)
Subsequent executions of the start method of the instance occur at the following relative time:
period + RAND(jitter)
To prevent schedule drift, subsequent executions ignore the jitter value of previous executions. For example, the second execution of the start method of an instance occurs at the following number of seconds after the instance transitioned to the online state:
delay + period + RAND(jitter)
The nth execution of the start method of an instance occurs at the following number of seconds after the instance transitioned to the online state:
delay + (n-1)period + RAND(jitter)
The persistent and recover properties can modify the time the periodic instance method runs when a periodic instance emerges from system downtime. The value of the recover property has effect only if the value of the persistent property is true.
If the value of the persistent property is false, the next execution of the start method for a periodic instance emerging from system downtime occurs at the following number of seconds after the instance transitions to the online state:
delay + RAND(jitter)
If the value of the persistent property is true and the value of the recover property is false, the next execution of the start method for the instance emerging from system downtime is scheduled for the following absolute time:
next_run + (n)period
If the value of the next_run property is in the future, n is 0. If the value of the next_run property is in the past, the smallest value of n is used that results in a future time. Subsequent invocations occur from that time according to the period and jitter values. The next_run property is described in Last and Next Start Method Invocations.
If the value of the persistent property is true and the value of the recover property is true, the periodic restarter invokes the start method for the instance as soon as possible as the instance emerges from system downtime. Subsequent invocations occur from that time according to the period and jitter values.
The periodic restarter service (svc:/system/svc/periodic-restarter) automatically attempts to restart if it terminates. When the periodic restarter service restarts after failure, the start method of each periodic instance is scheduled for the following absolute time:
next_run + (n)period
If the value of the next_run property is in the future, n is 0. If the value of the next_run property is in the past, the smallest value of n is used that results in a future time. Subsequent invocations occur from that time according to the period and jitter values. The next_run property is described in Last and Next Start Method Invocations.
If a periodic service instance is restarted, the start method for the instance is invoked at the following number of seconds after the instance transitions to the online state:
delay + RAND(jitter)
The start method should perform a task and then terminate within the time specified by the period property. If a contracted process still exists when the periodic restarter attempts to invoke the start method for the next period, then the invocation for that period is skipped and the periodic restarter attempts to invoke the start method again at the following period. The periodic restarter invokes the method again at the following number of seconds after the instance transitioned to the online state, where n is the smallest value that results in a future time:
delay + (n)period + RAND(jitter)
If the start method runs longer than the number of seconds specified by the timeout_seconds value, all processes in the contract are terminated and the invocation is a non-fatal fault. The first time the start method terminates in any non-fatal fault, the instance is placed into the degraded state and start method invocations continue as scheduled. If one of the following two invocations succeeds, the instance is placed back into the online state. After transitioning from the degraded state to the online state, the periodic restarter invokes the method at the following number of seconds after the instance initially transitioned from the offline to the online state, where n is the smallest value that results in a future time:
delay + (n)period + RAND(jitter)
After three successive non-fatal faults of the start method, the instance is moved from the degraded state to the maintenance state. On the first fatal fault of the start method, the service is placed into the maintenance state. See Repairing an Instance That Is Degraded, Offline, or in Maintenance in Managing System Services in Oracle Solaris 11.3.