In March of last year (some 18 months ago), the email below
started at thread here on opensolaris.org about improving SMF
import speed on the first boot:
http://mail.opensolaris.org/pipermail/smf-discuss/2006-March/004591.html
Has anything more come of this?
It seems like the thread led to the idea being squashed...?
Darren
David, all,
Thanks for the insight. With that information (and about 20
different reboots this morning :-) I finally got it working.
SMF repository build now takes about 30 seconds. Such a
difference for diskless client boots. Brilliant!!!
Here are the modifications to /lib/svc/method/manifest-import
that worked for me. The lines I had to add are all marked with
a "*" at the beginning:
...
312 #
313 # 2b. Import the manifests while giving a running display
of imports on
314 # console, and a final count in the logfile.
315 #
316 if [ -n "$nonsite_manifests" -o -n "$site_manifests" ]; then
317 rm -f /tmp/manifest_import.$$
318
319 set -- $manifests
320 backup=`echo "$#/$#" | sed 's/./^H/g'`
321 fwidth=`echo "$#\c" | wc -c`
322
323 echo "Loading smf(5) service descriptions: \c" >
/dev/msglog
324
* 325 SVCCFG_REPOSITORY=/etc/svc/volatile/fast_repository.db
* 326 export SVCCFG_REPOSITORY
* 327 cp -p /etc/svc/repository.db ${SVCCFG_REPOSITORY}
328
329
330 i=1; n=$#
331 while [ $# -gt 0 ]; do
332 printf "%${fwidth}s/%${fwidth}s" $i $n >
/dev/msglog
333 svccfg_import $1
334 i=`expr $i + 1`
335 shift
336 echo "$backup\c" > /dev/msglog
337 done
338
339 echo > /dev/msglog
340 echo "Loaded $n smf(5) service descriptions"
341 activity=true
342
343
344 if [ -s /tmp/manifest_import.$$ ]; then
345 echo "svccfg warnings:"
346 cat /tmp/manifest_import.$$
347
348 msg="svccfg import warnings. See"
349 msg="$msg
/var/svc/log/system-manifest-import:default.log ."
350 echo $msg > /dev/msglog
351 fi
352 rm -f /tmp/manifest_import.$$
353
* 354 pstop `pgrep svc.startd` > /dev/msglog
* 355 pstop `pgrep svc.configd` > /dev/msglog
* 356
* 357 cp ${SVCCFG_REPOSITORY} /etc/svc/repository.db
* 358 SVCCFG_REPOSITORY=/etc/svc/repository.db
* 359 export SVCCFG_REPOSITORY
* 360
* 361 pkill -9 svc.configd > /dev/msglog
* 362 pkill -9 svc.startd > /dev/msglog
* 363 exit 0
364 fi
...
As you see in lines 362-363 the way this works is to ultimately
kill svc.startd as well (which then gets automatically
restarted from the init process).
As svc.startd is the process who eventually calls the above
manifest-import script this means that manifest-import is run
twice. Thus the blunt "exit" in line 363 (during its first run).
Because the second time it is run (from the restarted svc.startd)
the repository is built and in its usual /etc/svc place, it
won't go through the above code section 2b anymore and comes
up just normally.
I am not sure if lines 358-359 are still needed to reset the
SVCCFG_REPOSITORY environment variable. I had them in there
from previous tries and I think they can probably be removed
as we are exiting this script 3 lines further down anyway.
From you comments
> ...So you should be able to pstop svc.configd, copy the
> repository back over, and then kill svc.configd. svc.startd
> will start a new svc.configd, which should use the updated
> repository.
it sounded like the restart of svc.startd would not be necessary
because svc.startd should not have a direct dependency on the
repository.db. However, there must be something, because when
I tried e.g. this (see code following further down), the boot
would just hang (never getting to the login prompt):
354 pstop `pgrep svc.startd` > /dev/msglog
355 pstop `pgrep svc.configd` > /dev/msglog
356
357 mv ${SVCCFG_REPOSITORY} /etc/svc/repository.db
358 SVCCFG_REPOSITORY=/etc/svc/repository.db
359 export SVCCFG_REPOSITORY
360
361 pkill -9 svc.configd > /dev/msglog
362 prun `pgrep svc.startd` > /dev/msglog
363 sleep 10
364 fi
So there is definitely some hidden dependency in svc.startd.
Anyway, I am thrilled we got a fast workaound by using /etc/svc/
volatile for manifest-import. This shaves a lot of time of our
diskless boots. (My department is creating and re-creating
diskless clients all the time and the SMF repository builds
at boot time were a major inefficiency factor).
Because I have only given this a few tries this morning, it would
be nice to get the SMF team with their svc.startd/configd inside
knowledge to look over the above workaround and point out in
case there are any concerns, e.g. any danger of ending up with
repository inconsistencies/corruption or the like.
Also, if a few other people are willing to try this out and
could post their experience (positive or negative) on this
thread that would be great.
Thanks,
--Marcus
