smfgen

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.

[sudo] npm install -g smfgen

JSON Input

Emits an SMF manifest for the service described by the given JSON:

Both the start and stop properties in the JSON should have object values that describe the context of the method. A method context consists of these properties:

A set of example methods might look like this:

{
    "start": {
        "user": "webservd", "group": "webservd",
        "exec": "/opt/pkg/sbin/apachectl start"
    },
    "stop": {
        "timeout": 120
    }
}

Note that you may also specify the properties that describe the context of a method at the top level of the JSON. Top-level properties apply to all methods, but may also be overridden in a specific method. For example:

{
    "user": "webservd", "group": "webservd",
    "exec": "/opt/pkg/sbin/apachectl %m",
    "timeout": 10,
    "stop": {
        "timeout": 120
    }
}

For compatibility with earlier versions of smfgen, the program will accept a string in place of an object for the start, stop, and refresh methods. This string will be assumed to be the exec property of that method.

Example

$ 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 &amp;" 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>

CLI Input

The following options can be specified over the CLI:

• -c, --category becomes data.category
• -d, --cwd becomes data.working_directory
• -D, --dependency appends to data.dependencies
• -e, --env appends to data.environment
• -g, --group becomes data.group
• -i, --ident becomes data.ident
• -l, --label becomes data.label
• -p, --privilege appends to data.privileges
• -r, --refresh becomes data.refresh.exec
• -s, --start becomes data.start.exec
• -S, --stop becomes data.stop.exec
• -t, --timeout becomes data.timeout
• -u, --user becomes data.user

Example

$ ./smfgen -i nginx -l 'NGINX Web Server' \
    -s 'nginx -d' -d /var/www \
    -u nobody -g other \
    -p basic -p net_privaddr \
    -eHOME=/var/tmp -ePATH=/bin:/usr/bin

<?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-nginx" >
    <service name="application/nginx" type="service" version="1" >
        <create_default_instance enabled="true" />
        <dependency name="dep0" grouping="require_all" restart_on="error" type="service" >
            <service_fmri value="svc:/milestone/multi-user:default" />
        </dependency>
        <exec_method type="method" name="start" exec="nginx -d &amp;" timeout_seconds="10" >
            <method_context working_directory="/var/www" >
                <method_credential user="nobody" group="other" privileges="basic,net_privaddr" />
                <method_environment >
                    <envvar name="HOME" value="/var/tmp" />
                    <envvar name="PATH" value="/bin:/usr/bin" />
                </method_environment>
            </method_context>
        </exec_method>
        <exec_method type="method" name="stop" exec=":kill" timeout_seconds="30" >
            <method_context working_directory="/var/www" >
                <method_credential user="nobody" group="other" privileges="basic,net_privaddr" />
                <method_environment >
                    <envvar name="HOME" value="/var/tmp" />
                    <envvar name="PATH" value="/bin:/usr/bin" />
                </method_environment>
            </method_context>
        </exec_method>
        <exec_method type="method" name="refresh" exec=":true" timeout_seconds="10" >
            <method_context working_directory="/var/www" >
                <method_credential user="nobody" group="other" privileges="basic,net_privaddr" />
                <method_environment >
                    <envvar name="HOME" value="/var/tmp" />
                    <envvar name="PATH" value="/bin:/usr/bin" />
                </method_environment>
            </method_context>
        </exec_method>
        <template >
            <common_name >
                <loctext xml:lang="C" >NGINX Web Server</loctext>
            </common_name>
        </template>
    </service>
</service_bundle>

Assumptions

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.
• 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.