SMF & legacy rc svccfg properties

Question

Hi,
-short version-
If indeed it does, then how and when does SMF import
legacy rc scripts to the repository, and how can you flush
them from the repository?
If SMF does not import rc scripts, why would moving a
start script from rc2.d to rc3.d not be correctly picked up
by /sbin/rc3? Are symbolically linked rc scripts, each
of which will have their own inode, open to wire-crossing
when run by lvscrun?
-long version-
I had understood that legacy rc*.d functionality was supported
by startd just kicking off any /sbin/rcN scripts as the appropriate
run level was reached. An FAQ somewhere says running init 2,
init 3, and so on should work fine: one needn't necessarily use svcadm -m multi-user.
But then I installed a 3rd-party app (Business Objects), the installer
of which dumped traditional scripts into init.d and rc*.d: an Sscript
and a in Kscript in rc2.d, nothing in rc3.d, and Kscripts everywhere below, using symlinks. A bit odd.
I only spotted this after rebooting, so I moved the Sscript to
rc3. This only ever runs as a Kscript at boot time or as a
result of init 3, but works fine as a start script when run manually.
Scratching my head, I wrote a wee wrapper Sscript in
rc3.d to call the real Sscript in the same directory. This
does cause the real Sscript to be called as a start script
at boot time. The relative orderings of the scripts do not matter.
This made no sense, so I had a look at SMF
svc:> select smf/legacy_run
svc:/smf/legacy_run> listprop
<snip>
rc3_d_S99BobjEnterprise110 framework NONPERSISTENT
rc3_d_S99BobjEnterprise110/contract count 81
rc3_d_S99BobjEnterprise110/inode count 1182
rc3_d_S99BobjEnterprise110/name astring /etc/rc3_d/S99BobjEnterprise110
rc3_d_S99BobjEnterprise110/state_timestamp time 1129192093.169780000
rc3_d_S99BobjEnterprise110/suffix astring BobjEnterprise110
The wrapper script is not listed under legacy_run, but the
original start script is.
The real solution, I know, is to write a manifest, and I ended up
doing that.
But how was the wrapper being run if SMF didn't know about it?
Are there svccfg commands to wipe out legacy entries, or is
editing/deleting/moving the original rc scripts enough?
From reading the comments in
http://cvs.opensolaris.org/source/xref/usr/src/cmd/svc/lsvcrun/lsvcrun.c
It seems the fact that the rc scripts were symbolic links might have
broken some of inode checks. Is that along the right lines?
I'm no C programmer...
Thank you for reading this far! :-)
cheers,
kidari

Answer 1

<snipped explanation: thank you for that!>
If I understand correctly, your problem is that at
first S99BobjEnterprise110 was not being run on boot,
but when you added a script which called it, it did
run and lsvcrun created a property group for
S99BobjEnterprise110. That does seem odd, since I'd
expect lsvcrun to create a property group named for
your wrapper script. It's worse that that. S99BobjEnterprise110 in
rc3.d was being called with the argument 'stop',
and therefore running as a Kscript, at boot time
and by init 3.
I determined this by putting
echo "$0 : $*">/var/tmp/distart.`date`
very early in the script: the command-line
args were only ever stop, and $0 was only
ever K01objEnterprise110 at boot or init 3
When I ran the script manually with
a 'start' arg: then it worked fine.
That pointed me in the direction of SMF
being confused by my having moved
S99BobjEnterprise110 from rc2 .d to 3.
The first place to look for
problems with lsvcrun is
/var/svc/log/milestone-{single-user,multi-user,multi-u
ser-server}:default.log, since that's where any
errors will be logged to. If they aren't
informative, then I'd try putting debug code in your
scripts and possibly /sbin/rc3.Right, I'll keep digging -- thank you for the help.
I'm reluctant to break everything again to reproduce
the error, now there's a manifest and all, but we'll
see....
Thanks again.