I'm with Matt on this. We shouldn't force people to use SMF if they don't want to. apachectl should behave exactly as expected as far as possible.
Shanti Matt Ingenthron wrote: > Hi all, > > Jyri Virkki wrote: >> Arvind Srinivasan wrote: >> >>> I think the issue is what interface we support. The only *supported* >>> interfac >>> for starting/stopping the Apache daemon on OpenSolaris should be SMF. >>> >> I'm ok with that. >> > > I'm not certain this is the right solution. > > While we want Solaris features, such as SMF, to be available and > advocated, one of the challenges with current Solaris for people who may > consider migrating is the fact that things are so different than most > other popular platforms. (more below...) >> >>> We could probably do something like this: >>> * Rename the existing apachectl to apachectl.private (or something) >>> * Add our version of apachectl that simply invokes SMF's svcadm >>> * 'svcadm enable/disable apache2' would invoke apachectl.private to >>> start/stop the server This way, the SMF property setting is the only >>> one that need be used (to select prefork vs worker) regardless of >>> whether the user invoked apachectl or svcadm. >>> >> +1 >> >> > > We may want to do this in the interim, but if it's practical to make > modifications to the apachectl script to use SMF and push them upstream, > that'd probably be better. Would bit be possible to do something like > that without wholesale replacing the apachectl and turning it into > apachectl.private (which is turning an upstream 'standard' interface > into a private interface)? > > This approach would make it work the way people expect it to and allow > people to adopt SMF at their own pace. > > It should also be possible to completely leave apachectl alone and just > wrap it with external SMF scripts, right? I guess the challenge here is > it would not hook into the service properties so well without changes to > apachectl as well... > > The other thing to be aware of here is we'd either want to be interface > compatible with apachectl or define what the interface mappings are > (i.e. stop vs. graceful vs. graceful-stop). Why? Keep in mind, there > could be customer installed monitoring/management modules that depend > upon things like the -V or -t -D flags. I just checked, and this even > includes the webmin included in Solaris. For instance, it seems to have > the ability to modify httpd.conf and test it with apachectl (from a > quick read of the .pl file in lib). > > There are, of course, some things that have no analogues necessarily, > like the -C or -d options (though -d could be a svcprop command followed > by an svcadm enable). I suspect they're less often used, but could > cause issues nonetheless. > > In any event, there should be a README.apachectl or something fairly > obvious right there in the directory to tell people what's going on with > this modified apache. > > - Matt >
