No, there was no intention to introduce any change in behavior. The patch , IMO, can provide a more closer integration to Solaris. customers still should get the same feeling of running 'apachectl start' or 'apachectl stop'. Internally, however, this would translate to the following sequence
user invokes apachectl start -> we internally patch apachectl start method to invoke svcadm enable -> SMF internally translates this and calls /lib/svc/method/http-apache2 -> where we now provide actual implementation to start the server. To switch to worker MPM, customer will need to manually set the SMF property before invoking apachectl start Hope this clarifies thanks sriram Mads Toftum wrote: > On Fri, Sep 07, 2007 at 06:19:43PM -0700, Sriram Natarajan wrote: > >> But, do you see any issue with still patching apachectl script to >> internally invoke SMF commands like svcadm enable / disable and moving >> the actual implementation of starting / stopping to >> /lib/svc/method/http-apache2 script >> >> > The more you want to patch apachectl, the more you risk affecting those > who use it expecting apachectl to be apachectl. > I thing you could do all that needs to be done in the svc method script > and let it either wrap apachectl or call the httpd binary directly. > Or if you do insist on hacking on apachectl, then at least make sure it > doesn't make any of the current methods behave differently. If you need > methods that behave differently, then at least name them such that there > will be no confusion. > > vh > > Mads Toftum > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20070910/b82a6cd7/attachment.html>
