Darren Reed wrote:
> Menno Lageman wrote:
>> Darren Reed wrote:
>>>> config/enabled boolean kernel accounting state
>>>>
>>> In what situations would config/enabled be true and the SMF
>>> property (general/enabled) that reflects the state of the service
>>> be false, or vice versa, thus disagreeing about the state of
>>> accounting?
>>>
>>> Or put differently, why isn't this property redundant?
>>>
>> Darren,
>>
>> the general/enabled property only determines whether or not the
>> configuration (whatever it may be) is restored upon boot. The
>> config/enabled property reflects the state of accounting in the kernel
>> (i.e. is the extended accounting subsystem active).
>>
>> It is perfectly valid to have a configuration with config/enabled
>> being false (e.g. after issuing 'acctadm -D task' to temporarily stop
>> writing accounting records while keeping the accounting file open) and
>> general/enabled being true. Upon boot this will restore the
>> configuration (set file name, tracked and untracked resources, do not
>> write records). So the property config/enabled is not redundant.
>
> I must have picked the wrong property... there is one that reflects
> the current status...anyway...
I think you have picked the right one. However the current 'state' of
extended accounting is not just config/enabled, it is the set of
config/enabled, config/file, config/tracked, and config/untracked
together that makes up the state of extended accounting for a particular
type.
> Why is acctadm the administrative interface here and not svcadm?
svcadm can only handle enable/disable of the instance; managing extended
accounting however encompasses more than just enable/disable. It also
allows specifying what resources to track, what file to write the
accounting records to etc. acctadm(1M) does all this. The 'smf state'
(i.e. the general/enabled property) of the instance only determines
whether or not we restore the last active extended accounting
configuration on the next reboot, nothing more. Compare it to
svc:/system/coreadm:default if you will: if it is enabled, the
configuration previously set using coreadm(1M) is restored on reboot.
> 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 is not forbidden to use svcadm enable/disable on the instance, it is
just that svcadm isn't rich enough to perform all configuration actions
one would want to do wrt configuring extended accounting.
> Or is your point that "acctadm -D task" temporarily disables all three?
>
> And to ask the question I was asking in a different way,
> can config/enabled be different to the status of the service
> as observed using svcs?
Yes it can. To quote my previous example, assume an admin has enabled
extended task accounting as follows:
acctadm -e basic -f /var/adm/exacct/task task
This will:
- enable extended accounting in the kernel for tasks,
- open /var/adm/exacct/task to receive task accounting records,
- set the tracked resources the resources in the basic set,
- set the config/enabled property to 'true',
- set the config/file property to '/var/adm/exacct/task',
- set the config/tracked property to 'basic',
- enable svc:/system/acctadm:task so the configuration is restored on
the next boot (thus setting general/enabled to 'true').
The admin can then use 'acctadm -D task' to stop writing accounting
records without closing the accounting file (this is existing
functionality btw, not something introduced by this case. See
PSARC/2001/424 for a state diagram).
This will:
- disable extended accounting in the kernel for tasks,
- set the config/enabled property to 'false'.
The instance will remain enabled since there still is configuration
(i.e. the accounting file name and the tracked resources) to restore on
boot.
> And if not, doesn't that then make config/enabled redundant? And if yes,
> does it make sense
> for the two to be able to disagree?
Yes. The key point is that general/enabled *only* determines whether the
configuration is applied on the next reboot or not. Nothing more.
There is normally no need to use svcadm(1M) to manage extended
accounting, everything is handled by acctadm(1M). If you enable extended
accounting, acctadm(1M) will enable the instance so the configuration is
restored the next time the system is booted.
Menno
--
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
