Troubleshooting SMF Service Startup
As I was working on my SMF scripts for the migration from Linux, I found some fancy ways to trace what was happening with a service that failed to start with new configuration.
There is a command called truss which allows you to follow along as something is being executed. See: man truss.
What I found really cool is that you can modify your existing SMF script from the command line. No need to make changes to xml and then reimport.
So back to the tip, if a service isn’t starting and you have eliminated all of the other possibilities with configuration, you need to see what the service script is doing. In my case, I was having a hell of a time with Red5. So here is what you can do:
Use to find what is the start method. In this case, /opt/local/share/red5/red5.sh:
[user@host ~]$ svcprop -p start/exec red5
Install a new start method:
[user@host ~]$ svccfg -s red5 setprop 'start/exec = “truss -f -a -o /tmp/truss.out red5.sh”'
Now try to start the service again:
[user@host ~]$ svcadm clear red5 [user@host ~]$ svcadm enable red5
Notice the clear command! That tripped me up several times when you would enable the service, but no warning was thrown about it being in maintenance mode.
Now go check the contents of /tmp truss.out to see what happened. My problem for red5 is that I was using a relative path to red5.sh. I specified in the environment that the working directory was /opt/local/share/red5. However, it appears that you still must specify an absolute path to the script.