Just evaluating zones and think, that putting the so called Sol N (with N < 10) /etc/init.d scripts into /lib/svc/method is a major design flaw. Why:
I think the most often use case (at least for my servers) are sparse zones. Thus /sbin, /usr, /platform and /lib are inherited read-only. For several reasons one may choose to not install software packages into the global zone (e.g. for security reasons (e.g. suid progs)), but into one sparse zone, only. But now one has a major problem, since /lib/svc/method is read-only, services can not be installed correctly anymore. A dirty workaround for SUNW packages might be to relocate the package (-a none). However, this usually doesn't work, since pathes are "hardcoded" into the manifest (e.g. /usr/share/man , /lib/svc/method aka do not honor BASEDIR) [beside the fact, that "relocatable" usually describes the missing / in the pkgmap entries, but real relocation was probably never on the plan of the packager]. SUNWsndmr might be sufficient for a case study. So actually I can't see, what problems are solved by putting the so called "init.d" scripts into /lib/svc/methods/, but I see, that this artificiallly creates a lot of problems and actually makes managing zones a lot harder than it could be and even requires package maintainers to create more complex install scripts (error prone) than usually required. RFE: So would you mind to consider /etc/svc/method as the primary place for startup scripts (which IMHO shouldn't break anything, if /lib/svc/method becomes a link to /etc/svc/method) ? This message posted from opensolaris.org
