This tool generates an SMF manifest from a JSON description of the service. It's only intended to generate simple manifests. For more details, see smf(5).
This tool is still experimental.
/*
* Emits an SMF manifest for the service described by the given JSON:
*
* ident The SMF identifier for the service. The full SMF
* identifier (FMRI) will be constructed from the category
* and identifier.
*
* [category] Service category (default: "application").
*
* label The human-readable name of the service.
*
* [dependencies] Array of service FMRIs that must be online before
* this service is started.
*
* start Script that starts the actual service. This invocation
* may run the service synchronously or in the background.
* Note that this mechanism does not allow you to use
* SMF's built in timeout for service startup, since it
* doesn't know when the service has actually started.
*
* [stop] Script that stops this service.
*
* [user] Run the start/stop methods as this user.
*
* [group] Run the start/stop methods as this group.
*
* [privileges] An array of RBAC privilege names. The start/stop
* methods will be run with this privilege set.
* See also: privileges(5).
*
* [environment] A hash of environment variables for the start/stop
* methods.
*/
$ cat bapi.json
{
"ident": "bapi",
"label": "Boilerplate API",
"start": "node bapi.js"
}
$ ./smfgen < bapi.json
<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<!--
Manifest automatically generated by smfgen.
-->
<service_bundle type="manifest" name="application-bapi" >
<service name="application/bapi" type="service" version="1" >
<create_default_instance enabled="true" />
<dependency name="dep1" grouping="require_all" restart_on="error" type="service" >
<service_fmri value="svc:/milestone/multi-user:default" />
</dependency>
<exec_method type="method" name="start" exec="node bapi.js &" timeout_seconds="10" />
<exec_method type="method" name="stop" exec=":kill" timeout_seconds="30" />
<template >
<common_name >
<loctext xml:lang="C" >Boilerplate API</loctext>
</common_name>
</template>
</service>
</service_bundle>
This tool makes a ton of assumptions about your service:
- Your service is a contract-model service in SMF. That means SMF should consider the service failed (and potentially restart it) if:
- all processes in the service exit, OR
- any process in the service produces a core dump, OR
- any process outside the service sends any service process a fatal signal See svc.startd(1M) for details.
- Your service is an application which depends on system services like the filesystem and network. This tool wouldn't work for system services implementing any of that functionality.
- If you specify any additional dependencies (like other services of yours), that means your service should not be started until those other services are online. However, if those services restart, your service will not be restarted.
- You only intend to have one instance of your service, and it starts off enabled.
- SMF provides a mechanism for timing out the "start" operation. But for simplicity, this tool always runs your start script in the background, so as far as SMF sees it starts almost instantly. If you want to detect "start" timeout, you must implement a start method that returns exactly when your program has started providing service (e.g., opened its server socket), and you'll have to write your own manifest rather than use this tool.
- By default, the "stop" method just kills all processes in this service, which includes all processes forked by the initial "start" script. You can override this with a "stop" script, but you should use the default if that script is only going to kill processes. There's a default 30 second timeout on the stop script, so the processes must exit within about 30 seconds of receiving the signal.
- The service does not use SMF to store configuration properties.