Jitter and delay for svcbundle generated SMF manifests

Another extenstion to the svcbundle tool is the introduction of -s delay= and -s jitter= for periodic SMF services services. If you have something to start in a periodic manner it’s really easy to create a service with svcbundle

Let’s assume you have a small script called /root/demo_periodic.sh:

root@solaris:~# cat demo_periodic.sh
date >> /root/periodic_service

You want to run it every minute. As the script need some other stuff running, you don’t want to start it right after startup of the system or the restart of the services , but only three minutes later. And don’t want t start it every minute sharp as you anticipate to many processes would start at right that moment, as many other users have such a periodic job as well.

The periodic service already knew concepts like jitter and delay. Jitter controls how many seconds a periodic service additionally waits with the execution after period has passed.

Delay controls how long it should wait with the first execution the script in the periodic service after the service transitioned into online for example after boot.

This was available in SMF for quite a while. However with this recent addition via an SRU you can now control jitter and delay with with svcbundle as well.

So now it’s really simple to create such an service. With -i you can even install it right with the command. It starts at one based on the configuration.

svcbundle -i -s service-name=site/demoservice \
 -s start-method=/root/demo_periodic.sh \
 -s jitter=10 \
 -s delay=180 \
 -s period=60

I asked for the time right after executing the last command. The service already enabled at this moment.

root@solaris:~# date
Montag,  8. März 2021 um 18:38:58 Uhr UTC

In the following output you see the consquence of jitter and delay at once:

root@solaris:~# head -n4 periodic_service
Monday, March  8, 2021 at  3:42:02 PM UTC
Monday, March  8, 2021 at  3:42:57 PM UTC
Monday, March  8, 2021 at  3:44:06 PM UTC
Monday, March  8, 2021 at  3:45:04 PM UTC

The service only starts after three minutes since we enabled the service (first line). This is the consequence of delay. When you look at the varying time differences between the executions, you see the consequence of jitter