When you use the svcbundle command to create a scheduled service, you must specify the interval property as well as both the service-name and start-method properties. By default, svcbundle creates a transient service. When you specify -s period, svcbundle creates a periodic service.
In this example, the start method for this service is named scheduled-ex. Copy this executable to /lib/svc/method/scheduled-ex.
In this example, the service name is site/scheduled-example. Specify an interval for the start method scheduling. Do not specify any of the following properties: bundle-type, duration, model, rc-script, refresh-method, or stop-method.
A scheduled service should use the fewest scheduling constraints required to schedule the task. In the following example, the periodic restarter will execute the start method for the service every Sunday between 02:00 and 03:00. To invoke the method between 02:00 and 02:01, add the constraint minute='0'.
$ svcbundle -o /tmp/scheduled-example.xml -s service-name=site/scheduled-example \ > -s start-method=/lib/svc/method/scheduled-ex -s interval=week -s day=Sunday -s hour=2
When you specify the interval property, svcbundle creates a scheduled_method element, which causes the restarter for the service to be set to the periodic restarter when the manifest is imported. The value of the interval property becomes the value of the interval attribute of the scheduled_method element. The value of the start-method property becomes the value of the exec attribute of the scheduled_method element.
The /tmp/scheduled-example.xml manifest is shown in Example 6, Example Scheduled Service Manifest.
Verify that the content of the manifest is what you need. You might want to make changes such as the following:
Specify additional constraints in the scheduled_method element.
Specify additional property groups of type scheduled, as described in Scheduling Invocations at Irregular Intervals.
Add a method_context element in the scheduled_method element.
Add comments and fill out template elements to describe what the service does and how the properties of the service are used.
$ svccfg validate /tmp/scheduled-example.xml
$ cp /tmp/scheduled-example.xml /lib/svc/manifest/site/scheduled-example.xml
$ svcadm restart manifest-import
Verify that the new service exists and is in the expected state.
$ svcs scheduled-example $ svcs -l scheduled-example $ svcprop -p scheduled scheduled-example:default
The example in this procedure produced the following manifest:
<?xml version="1.0" ?> <!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> <!-- Manifest created by svcbundle (2020-Oct-01 17:21:24-0700) --> <service_bundle name="site/scheduled-example" type="manifest"> <service name="site/scheduled-example" version="1" type="service"> <!-- The following dependency keeps us from starting until the multi-user milestone is reached. --> <dependency name="multi_user_dependency" grouping="require_all" restart_on="none" type="service"> <service_fmri value="svc:/milestone/multi-user"/> </dependency> <scheduled_method recover="false" exec="/lib/svc/method/scheduled-ex" interval="week" day="Sunday" hour="2" timeout_seconds="0"/> <instance name="default" enabled="true"/> <template> <common_name> <!-- Replace loctext content with a short name for the service. --> <loctext xml:lang="C"> site/scheduled-example </loctext> </common_name> <description> <!-- Replace loctext content with a brief description of the service --> <loctext xml:lang="C"> The site/scheduled-example service. </loctext> </description> </template> </service> </service_bundle>