C. Bergstr?m wrote: > Stephen Hahn wrote: >> * "C. Bergstr?m" <cbergstrom at netsyncro.com> [2008-11-26 11:55]: >> >> (These are really questions for smf-discuss at opensolaris.org. I'm not >> closely working on smf(5) at the moment.) >> >> >>> 2) Building svc/* is a pita in a few ways.. >>> a. It pulls in objects from other places so to avoid static libs being >>> built.. (or is just (ab)using the fact that it's in onnv and assumes a >>> monolithic build >>> >> It's actually because we support building on a system with older >> versions of the libraries--we build a native version of the possibly >> newer svc.configd and svccfg. >> >> >>> b. during the build it also bootstraps the base *.db (which is perfectly >>> logical 99.9% of the time) >>> c. There's a lot of deps involved here.. from perl to a rather long list >>> in my notes... >>> ( /usr/bin/perl -w listsvcs.pl -e generic_open.xml inetd_generic.xml >>> >>>> check_open.enabled) >>>> >> Yep. >> >> >>> Because of some of the small changes I made to svc.* I expected problems, >>> but even with -kv -m milestone=none I was able to hang the start-up process >>> in a way to completely render sending break over serial useless.. (It hung >>> tip/c-kermit.. etc) (On the console if I wasn't redirecting I could F1+a, >>> but typing stacks isn't fun) I know how to work-around that now and it >>> will be included in my final docs.. >>> >> The seed is determined to be critical. If one was planning a >> substantial alteration of the startup portion of the graph, a new >> membership for the seed repository would be required. >> >> >>> Is there any from ground up guide/docs on how to bootstrap svc's *.db? >>> >> None that I know of. The original seed repository was constructed >> based on working through the various supported boot scenarios, of >> which there are many. OpenSolaris-distro will probably support fewer >> such scenarios--but there are new ones coming, too. >> >> >>> Here's some of my references currently >>> cmd/svc/seed/Makefile >>> cmd/svc/milestone/README >>> >>> cmd/svc/milestone/README.share >>> (really interesting in parts.. small nit.. the reference to failsafe should >>> be removed or even better added back into OpenSolaris, but I can understand >>> why it was removed.. so...) >>> >> I'm sure we'd take corrections/patches to these documents. >> >> >>> I also think the concept of sbd was lost somewhere since this pulls a 404 >>> (maybe it's behind the firewall?) >>> cmd/svc/profile/README - http://solsec.eng.sun.com/sbd/ >>> >> >> This link is probably covered in the "secure by default" pages for the >> security project: >> >> http://opensolaris.org/os/community/security/projects/sbd/ >> >> >>> On a mostly default Opensolaris install I see about 90 services started.. >>> From here my goal is to document each one and try to establish a milestone >>> just above single user, but still absolute minimum with all networking. >>> (This has probably been done -minus the documenting)
I think that network/service's dependencies are supposed to capture this state, but I'm not sure that original goal was strictly respected. It'd be interesting to hear what you find. >> It depends on what you want to be active, beyond single-user. It's >> probably worth noting that new milestones that you wish to use with >> "svcadm milestone" require support in svc.startd(1M) and probably >> elsewhere. >> >> But I recommend asking on smf-discuss--they're the experts. >> > Oopse. thanks for you and Shane pointing this out.. My focus hasn't been > on smf until now and missed this list.. > > afaik.. I can't attach patch to the bugzilla.. (even if rumor is that > will soon change) Anyway.. 1) the above are nits and 2) I doubt anyone > outside myself or a Sun employee has really cared to read them much.. > > When it comes to building against a multilib based system there's other > more elegant ways to depend on specific versions than > > LIBSQLITE = $(ROOT)/usr/lib/libsqlite.o It's not just to depend on a specific version -- it was to be resilient to the fact that the build server probably didn't have libsqlite installed at all. (It still doesn't, and nobody's proposed to ship a copy we could statically link against anyways.) > To really explain why this should be avoided is an entirely different > thread I won't bore anyone here with.. > -------------- > I'm done some basic optimizations on smf parts and during the build > > for m in ../milestone/boot-archive.xml ../milestone/devices-local.xml > ../milestone/global.xml ../milestone/identity.xml > ../milestone/local-fs.xml ../milestone/manifest-import.xml > ../milestone/minimal-fs.xml ../milestone/multi-user.xml > ../milestone/name-services.xml ../milestone/network-initial.xml > ../milestone/network-loopback.xml ../milestone/network-physical.xml > ../milestone/restarter.xml ../milestone/root-fs.xml > ../milestone/single-user.xml ../milestone/usr-fs.xml > ../../dlmgmtd/dlmgmt.xml ../../rpcbind/bind.xml; do \ > echo $m; \ > SVCCFG_DTD=../dtd/service_bundle.dtd.1 \ > SVCCFG_REPOSITORY=/work/onnv-gate/usr/src/cmd/svc/seed/common.db \ > SVCCFG_CONFIGD_PATH=../configd/svc.configd \ > ../svccfg/svccfg import $m; \ > done > > > I get this nice little core I need to debug > > svccfg_libscf.c:1884: scf_transaction_commit() failed with unexpected > error -1. Aborting. > sh: line 2: 15122: Abort(coredump) > *** Error code 6 > > > It's triggered on.. > > ../milestone/global.xml \ > ../milestone/multi-user.xml > ../milestone/restarter.xml > > ../milestone/console-login.xml \ > ../../cmd-inet/usr.lib/inetd/inetd-upgrade.xml \ > ../milestone/network-service.xml > ../../nscd/name-service-cache.xml > > > > I've changed dev env in the middle of all this and hoping to dodge > debugging this until after I get network is up on the target.. (which as > I'm finding out may not be svc related, but some other issue entirely) > > So then comes questions like.. > > 1) Are any of these critically important (looks to be yes, but maybe I > can get network up w/o it) I'm guessing you'll care about console-login and network-service. I can't be sure we're resilient to an absent restarter service, but it's at least possible. > 2) Where does common.db/global.db go after after the build or where/how > does the initial database get built/populated? Currently, the installer places the appropriate seed into /etc/svc/repository.db. Then svc:/system/manifest-import takes care of importing the rest. It'd be ideal if when repository.db was missing, configd attempted to populate it from one of the well-known seeds in /lib/svc/seed, but it's a bit tricky and we haven't prioritized that enhancement yet. liane
