Darren Reed wrote:
> Menno Lageman wrote:
>> Darren Reed wrote:
>> ...
>>> Why wouldn't you use "svcadm disable -t system/acctadm:flow" ?
>>
>> This wouldn't be particularly useful since these are transient
>> services that perform a configuration action at boot only (disable -t
>> only lasts until the next reboot). There is no daemon running for them
>> when the instance is enabled.
>
> It isn't necessary for there to be a running daemon to have
> an SMF instance report itself as being "enabled."
Yes I know that. That's not what I said however; what I said is that
temporarily disabling the instance isn't particularly useful here because:
a) disabling the instance (for this particular service) *only* means 'do
not apply the extended accounting configuration on boot' because its
start method will not run at next boot. It does not twiddle any bits in
the kernel at the time you disable the instance (nor is there a running
daemon to do such twiddling, because this is a transient service),
b) the effect of svcadm disable -t only lasts until the next reboot by
definition, i.e. if the instance is currently enabled, disable -t will
disable the instance until the next boot, at which time the instance
will be enabled again (because you only temporarily disabled the
instance). Since it doesn't twiddle any bits when being svcadm disabled,
the net effect is zero.
Hence the not 'particularly useful'.
> But my reading of the materials indicates that "diable -t"
> is roughly equivalent to what happens with the "-D" switch
> for acctadm.
No, it is not. svcadm disable -t has no impact on the active in-kernel
configuration. acctadm -D does.
> This is a problem.
>
> What I see here is that you're putting a layer on top of SMF
No I'm not, I'm using the services provided by smf(5). This is no
different from what e.g. the svc:/system/coreadm service does. There the
configuration properties themselves are managed using coreadm(1M), to
see the current coreadm configuration, one uses 'coreadm'. Disabling
svc:/system/coreadm:default *only* means that the coreadm config is not
applied at the next boot because its start method, which applies the
saved config using coreadm -u, does not run. Issuing a 'coreadm -d
global' updates the in-kernel state, it does not disable the service
instance. Even if you'd 'svcadm disable coreadm' nothing would happen to
the in-kernel state because the service has no stop method. You will
only prevent the last active configuration from being applied at boot.
This extended accounting service does exactly the same, so we're not
inventing something new here. The difference is that the coreadm service
is always enabled and never disabled, while the acctadm service is
disabled until the administrator enables extended accounting using
acctadm(1M), at which time the corresponding service instance is enabled
since there is now configuration to apply at the next boot.
> To expand upon your above example, if you do:
> # acctadm -D task
> then shouldn't this command:
> # svcs -x svc:/system/acctadm:task
> also say that the SMF instance is temporarily offline?
No, see above. Disabling the instance only means 'do not apply the
configuration at boot'.
> Why should a user be forced to do:
> svcprop -c -p config/enabled svc:/system/acctadm:task
> in order to find out what the current state of accounting
> is because svcs doesn't tell the whole story?
The user *isn't* forced to use svcprop to find out the state, they are
actually discouraged from doing so. They should use acctadm(1M) to find
out about the state of extended accounting:
ml93401 at kahless $ acctadm
Task accounting: active
Task accounting file: /var/adm/exacct/task
Tracked task resources: basic
Untracked task resources: host,mstate,anctaskid,zone
Process accounting: inactive
Process accounting file: /var/adm/exacct/process
Tracked process resources: none
Untracked process resources: extended,host
Flow accounting: inactive
Flow accounting file: none
Tracked flow resources: none
Untracked flow resources: extended
This is how it works today and how it will keep working after this case.
In fact, this case classifies the config/* properties as Project Private
just for this reason. The user is not expected to modify/observe these
properties using smf(5) tools such as svccfg and svcprop. They should do
so using the existing interface provided by acctadm(1M).
> Why is it necessary to use a different administative
> interface (check the config/enabled property) of this
> SMF instance to observe its state than for other services
> managed by SMF (ie svcs)?
It isn't necessary to check config/enabled (or any other property) at
all to observe the state of extended accounting: acctadm(1M) is the
interface that provides this information (now and in the future). The
reason being that the value of 'config/enabled' by itself does not
completely represent the state of extended accounting. The config/file,
config/tracked, and config/untracked properties are part of its state too.
Only if config/enabled is false *and* config/file is unset *and*
config/tracked is unset, can extended accounting be considered 'not
active'. At that time only, the service instance will be 'disabled' in
the smf sense of the word since there is no effective configuration to
apply at boot. All other combinations of these four config properties
result in extended accounting being 'active', thus resulting in the
service instance being 'enabled' (again, in the smf sense of the word)
because there is configuration to apply at boot. The enabling/disabling
of the service instance is done by acctadm(1M) as a result of the user
calling acctadm with the appropriate arguments to modify the configuration.
> In your proposed model, if I do "svcs -a | grep offline",
> or similar, accounting that has been disabled via acctadm
> (using -D) will have its running state incorrectly reported.
No. The enabled/disabled state of the instance (general/enabled) only
signifies 'restore the configuration at boot or not'.
> This and that I have to use another command to correctly
> determine the state of accounting is of great concern.
No, you only need *one* command to manage and determine the state of
extended accounting: acctadm(1M). An unadorned 'acctadm' will tell you
the state of the extended accounting configuration. Just like it does today.
> Is there a reason why the model can't be:
> - use acctadm to provide an easy way to manage the properties
> of the extending accounting services;
That is exactly the model this case provides.
The smf state (general/enabled) is only interesting insofar as to see
whether or not the current configuration will be applied on the next
boot. Nothing more.
Menno
--
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
