1service_bundle(4) File Formats service_bundle(4)
2
6 service_bundle - service manifest file format
7
9 /usr/share/lib/xml/dtd/service_bundle.dtd.1
10
13 The service management facility, described in smf(5), utilizes an XML-
14 based file format to marshal the description of a set of services or
15 service instances between systems. This file is known as a service bun‐
16 dle. The primary form of a service bundle is the inventory of services
17 that are provided by a package, which is called a service manifest.
18 The DTD describing the service_bundle is provided at
21 /usr/share/lib/xml/dtd/service_bundle.dtd.1. The attributes and tags
22 are fully described in the commented DTD. The services supplied with
23 the operating system, stored under /var/svc/manifest, provide examples
24 of correctly formed service descriptions.
25 service_bundle documents can also use the XML Inclusions (XInclude)
28 facility to merge multiple documents into one. A service_bundle docu‐
29 ment manipulator must therefore support the functionality defined by
30 the XInclude specification.
31 A complete service description consists of the following:
34 o A set of properties that identify the service and identify
36 its restarter
37 o A set of properties that identify each instance
39 o A set of framework property groups that describe the frame‐
41 work's understanding of each instance
42 o A set of method property groups as required by
44 svc.startd(1M), or by a delegated restarter
45 o Additional optional method property groups
47 o A set of dependency property groups
49 o An optional group of properties that indicate services to
51 which dependencies on the described service were added
52 o A set of application property groups or application-specific
54 typed property groups containing application configuration
55 data
56 o A template that describes supporting information about this
58 service, such as a description, links to documentation, and
59 metadata about property groups and properties.
60 The document type definition for the service bundle provides markup to
63 define each of these aspects of a service description, as well as a
64 number of entities that identify regular features in describing a ser‐
65 vice, such as the <create_default_instance> tag.
66 Manifest Handling During Packaging Operations
68 Service manifests within packages should be identified with the class
69 manifest. Class action scripts that install and remove service mani‐
70 fests are included in the packaging subsystem. When pkgadd(1M) is
71 invoked, the service manifest is imported.
72 When pkgrm(1M) is invoked, instances in the manifest that are disabled
75 are deleted. Any services in the manifest with no remaining instances
76 are also deleted.
77 If the -R option is supplied to pkgadd(1M) or pkgrm(1M), the actions
80 described in this section are done when the system is next rebooted
81 with that alternate root path.
82
84 See attributes(5) for descriptions of the following attributes:
85 ┌─────────────────────────────┬─────────────────────────────┐
90 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
91 ├─────────────────────────────┼─────────────────────────────┤
92 │Availability │SUNWcsu │
93 ├─────────────────────────────┼─────────────────────────────┤
94 │Stability │Committed │
95 └─────────────────────────────┴─────────────────────────────┘
96
98 pkgadd(1M), pkgrm(1M), svcadm(1M), svccfg(1M), svc.startd(1M), lib‐
99 scf(3LIB), attributes(5), locale(5), smf(5), smf_method(5), smf_tem‐
100 plate(5)
101
103 Nested service_bundle elements must be of the same type.
104SunOS 5.11 6 Mar 2009 service_bundle(4)