Adding environment variables to an SMF service

I create an SMF manifest last week for a new service, and needed two environment variables to be set prior to the services’ start method being invoked. After poking around the svccfg manual page, I came across the setenv subcommand, which can be used to set an environment variable:

$ svccfg -s tinydns setenv FOO bar

Since I was creating a manifest from scratch, I ran this against a temporary service and then used the svccfg “export” command to display the entry I needed to add to the manifest I was creating:

$ svccfg export tinydns

Here is the XML that was displayed for the environment variable addition:

<exec_method name=’start’ type=’method’ exec=’/lib/svc/method/tinydns start’ timeout_seconds=’60’>
<envvar name=’FOO’ value=’bar’/>

I like SMF, but sometimes wonder if it is over-engineered for what it actually needs to do. If you have opinions on this, please let me know by submitting a comment.

10 thoughts on “Adding environment variables to an SMF service”

  1. I can name few likable additions to SMF: monit style monitoring integration, more consistent service naming scheme and dealing with different service versions(it is also packaging problem).

  2. I like the SMF also. I find it difficult to sell people on using it who are used to using scripts in the rc directories. Some SA’s (and dba’s) I know have a hard time understanding how it works and don’t bother with it.

    Thanks Matty for this tidbit.

  3. Imho this way you have standalone environment bound to service without risk of modification by tampering, service failure or such. Good deal for one subcmd.

  4. I already hated the complicated startup configuration of Windows since the move from win.ini to the registry, and now Solaris has to adopt that crap..
    I don’t really see any advantage in the new concept, it only gives the admin more work when installing new software. The whole system is poorly documented unless one wants to learn usage by reading the included service XMLs and guessing what the parameters do. Cloning zones or machines can now really screw you over with un-startable services even if you remember to edit the method scripts as long as you don’t nuke the old service database and re-import the service(s), because Solaris doesn’t actually read the method files anymore once imported.
    Simply copying an init script and changing the program command line was so much easier. Extending the old system in a compatible way (e.g. with an envvar naming the process to be watched by the restarter daemon) would have been a better idea.

    Adding such niceties as svccfg and inetcfg being a subset of each other and working on the same service concept, yet still having a different command set and syntax, just adds to the dread.
    Last.. why does everything have to use XML now? It’s such a bloat to write.. a simple parameter=value list has a far better size-to-payload ratio. Markup tags in config files are just useless.

  5. I think my only comment follows Woo’s a little above. I like SMF, and I appreciate what a well written service can do that an rc.d stop/start script cannot.

    I don’t find xml entirely unmanageable, but I do find svccfg completely useless – so I consistently write my own manifests from scratch. For that reason alone, I’d appreciate a more ‘unixy’ (and less ‘Solarisy’) interface to services – ideally a simple flat file with a straightforward and self-evident format.

    xmllint helps.

  6. I agree with pretty much every word Woo said above. XML has no business being edited by a human – EVER – it is fine for moving data between processes.

    I like what SMF does – restarting processes and dealing with dependencies, but it could do it just as well without XML.

    There should be an award for the least appropriate use of XML…

  7. Matt, Paul, you’re spot on. As much I like the functionality of SMF, XML should NEVER be human edited and it IS totally over-engineered.

  8. Found this page via Google — great post, great comments. Man, am I ever impressed with svccfg. I kind of liked SMF before today, but using it to update a service’s environment today was awesome, and using the export feature just now to dump out the XML was even better.

    This is really, really impressive.

Leave a Reply

Your email address will not be published. Required fields are marked *