[ re-sending to avoid opensolaris bounce ] Mats,
On Mon, Nov 13, 2006 at 08:06:43PM +0100, Mats Kindahl wrote: > #!/sbin/sh > > . /lib/svc/share/smf_include.sh > > NAME=inadyn > DAEMON=/usr/local/bin/$NAME > . > . > . > case $1 in > start) > if [ ! -x $DAEMON ]; then > echo "$DAEMON is not executable, not starting" > exit $SMF_EXIT_ERR_CONFIG > fi > if [ ! -r $CONF ]; then > echo "$CONF not readable, not starting" > exit $SMF_EXIT_ERR_CONFIG > fi > if pgrep $NAME >/dev/null; then > echo "'$NAME' is already running" > else > $DAEMON & > sleep 1 > fi > ;; > . > . > . > esac > > exit $SMF_EXIT_OK > > When I call the 'inadyn-client' script directly, the daemon starts well > and keeps going without a glitch, but when svc.startd tries to start it, > it decides somehow that "all processes in the service exited". AFAICT, > this is not the case. As others have pointed out, pgrep will find the script itself, and needs to be more selective. It sounds like you have done so and achieved some degree of success. There are deeper problems, though. The start method interface requires that when you return SMF_EXIT_OK, your service has been started and is ready to offer service. Services which depend on yours can be started as soon as you return; if you aren't really ready, they might fail. Backgrounding the daemon and waiting a second is, frankly, a hack that won't always work. That said, you can get away with this as long as your service doesn't have dependents, or the dependents are robust enough to tolerate a lack of availability. The more serious problem is that if the daemon (or an unfortunately named program also found by pgrep) is already running, your service will fail once again because "all processes in the service exited". SMF can only monitor the health of processes it starts, and moreover has no way to know that some other set of processes should be important to it. If your start method thinks it has found another copy of the daemon running, it should return SMF_EXIT_ERR_NOSMF. The service will still fail, but will do so for a legitimate, understandable reason. > So, the questions are: > - How do svc.startd decide if a process is in the service? Every process and subprocess started from the start method of a service belongs to that service, unless one of those processes specifically requests otherwise for its children. Dave