Installing a daemon on Solaris 10

Solaris 10 implements SMF, I wanted to have my shell script run at system boot and make sure it runs reliably in the background. SMF is your friend on Solaris 10.


1. Create a file <file>.xml with the following contents
8<------------------8<------------------8<------------------8<------------------
<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<!--
Service manifest for my daemon.
-->

<service_bundle type='manifest' name='inetconv:mydaemon'>

<service
name='network/mydaemon'
type='service'
version='1'>

<create_default_instance enabled='true'/>

<restarter>
<service_fmri value='svc:/network/inetd:default' />
</restarter>

<!--
Set a timeout of 0 to signify to inetd that we don't want to
timeout this service, since the forked process is the one that
does the service's work. This is the case for most/all legacy
inetd services; for services written to take advantage of SMF
capabilities, the start method should fork off a process to
handle the request and return a success code.
-->
<exec_method
type='method'
name='inetd_start'
exec='/opt/hans/daemon.sh'
timeout_seconds='0'>
<method_context>
<method_credential user='hans' group='other' />
</method_context>
<propval name='arg0' type='astring'
value='hans' />
</exec_method>

<!--
Use inetd's built-in kill support to disable services.
-->
<exec_method
type='method'
name='inetd_disable'
exec=':kill'
timeout_seconds='0'>
</exec_method>

<!--
This property group is used to record information about
how this manifest was created. It is an implementation
detail which should not be modified or deleted.
-->
<property_group name='inetconv' type='framework'>
<propval name='converted' type='boolean' value='true' />
<propval name='version' type='integer' value='1' />
<propval name='source_line' type='astring' value=
'mydaemon stream tcp nowait hans /opt/hans/daemon.sh mydaemon'
/>
</property_group>

<property_group name='inetd' type='framework'>
<propval name='name' type='astring' value='hans' />
<propval name='endpoint_type' type='astring' value='stream' />
<propval name='proto' type='astring' value='tcp' />
<propval name='wait' type='boolean' value='false' />
<propval name='isrpc' type='boolean' value='false' />
</property_group>

<stability value='External' />

<template>
<common_name>
<loctext xml:lang='C'>
Redwood Network Agent
</loctext>
</common_name>
</template>
</service>

</service_bundle>
8<------------------8<------------------8<------------------8<------------------

Note: Please change the UID to the UID of your user and change the path as well as mydaemon, unless you want to keep that name ... ;-).

2. Import the xml file with

svccfg -v import <file>.xml

3. Check the service with

svcs -v mydaemon

easy backport

I am a tech writer, and sometimes, just after a branch, I frequently have two checkouts living side by side, one for each version. Since the branch was made very recently, the files are still the same, so contain the same bug.

Since I keep version numbers in the path, head is 200, and will remain so until v3 is out.

Ex:

~/cvs_200/doc/xml/somedir
~/cvs_203/doc/xml/somedir

Often I am far down in the fs and

Once I have fixed the bug on head, I run:

cd `echo \`pwd\` | sed -e 's/200/203/'`
cvs up -j HEAD file.xml
cvs commit

ldd, otool and flushing dns

The other day I needed to check which libs an executable was linked against, on linux I would use ldd, but on my Mac OS X there is no tool called ldd. I found otool with the -L option did the trick.

otool -L `which awk`

Btw, LD_LIBRARY_PATH on Darwin (Mac OS X) is DYLD_LIBRARY_PATH, more information available in the man page, man dyld.


Another issue I get is when I want to flush the dns cache of my mac, I have recently purchased a white MacBook with Leopard on it and the

lookupd -flushcache

does not work anymore, in Leopard (10.5) it has become

dscacheutil -flushcache