>> If we can modify apachectl interface (like adding more options),
>> then there is no need for another script.
>
> Please be mindful about stating whether you are talking about public
> interfaces or implementation detail whenever you refer to "another
> script", as it makes all the difference...
Sorry for not being clear. I was talking about public interfaces.
> IF you meant yet another public interface to start the server, no,
> that is not an option. It's important there be no confusion here!
> There are only two public interfaces:
Yes, I was suggesting adding a new public interface to start/stop the server.
> - "svcadm enable apache2" - the formal Sun-supported way
> - "apachectl start" - the well-known way from the apache community
>> I would like to know
>>
>> 1. If apachectl interface can be modified?
>
> Not incompatibly. If it needs to be extended, sure, that is a
> possibility. In general I'd like to minimize changes to the upstream
> code mainly to minimize maintenance efforts. But any change that
> justifiably makes sense is welcome for discussion.
>> 2. If no, then should we ask the users to manually invoke svcamd commands ?
>
> Of course! That's the primary documented interface! "svcadm enable apache2"
> There is no "if" about it.
I agree, "svcadm ... " is the documented interface. But without a wrapper,
that would be the only way to start/stop apache server in smf mode.
I was suggesting another interface like apachectl.smf (to avoid changes to
apachectl)
which would be similar to apachectl but would be used for smf mode operations.
So,
apachectl start -> would start the server in non-smf mode
apachectl.smf start -> would start the server in smf mode
and an user familiar with smf, could still use
svccfg -s apache2 setprop pg/name = value -> whenever needed
svcadm enable apache2
But, since adding a new interface (apachectl.smf) has been ruled out,
it would purely be an implementation issue. So, this will no longer be an
open issue as far as the ARC case is concerned.
Thanks,
Seema.
