Mike Gerdts wrote: > Based upon the fact that your rcS.d script is rebooting prior to > getting a console login prompt, I would guess that init(1M) is > correct. I betchya that you could move your start script to > /etc/rc1.d and you would get console-login to start before your > script, yet it would still run your start script when you boot -m > single-user:default.
I have never fully understood rc1, but (a) I'm pretty sure that the rc1 stuff doesn't run in traditional startup unless you explicitly request it, and (b) I don't see any way that it can get run under SMF. > That being said, adding a service that inserts itself between > svc:/system/console-login:default and > svc:/milestone/single-user:default would probably be the most reliable > mechanism. That's a very clever idea! Unfortunately, it looks to me like it doesn't work. It looks like system/console-login is _not_ the single-user login prompt. It looks like it's the rc1 login prompt, or maybe the multi-user login prompt for the console. (I'm a bit confused about when it gets run, but I'm pretty sure it's *not* at single-user mode.) It looks like sulogin (the single-user login prompt) gets run magically after milestone/single-user comes online. (See usr/src/cmd/svc/startd/specials.c.) It also gets run magically if certain other services fail to come online. > A "sleep 60" before the reboot would probably help you out of the > reboot loop. We already have one. I'm told (though I haven't researched it myself) that it works fine under S8 and S9 but that it appears that SMF is helpfully protecting us from the ^C. > This would probably annoy people like me that complain > about multiple reboots being required to install patches. Yeah, we know that's a major pain point. We normally ignore the "reboot immediately" flag and defer the reboot to after all of the patches have been installed. (There are a couple of patches where we set a "no, we really mean it" flag.) I don't like it, but the field insisted that that's the way they configure the product any way. The real solution is to reduce the number of patches that demand an immediate reboot. (See 117127-03 for an extreme example.) Talk to the people who create the patches about being smarter about when they use that flag and about making their software more patch-friendly. I believe the kernel people hope to do some magic with Indiana that will make the picture better. I don't know any details. > Alternatively, "boot -m milestone=none" is your friend to recover from > the reboot loop induced by rcS.d scripts. That works, but like the comment in the old /etc/rcS says about boot -b, "this is a clear act of desperation". Milestone=none is a really unpleasant environment.
