On Nov 12, 2009, at 7:22 AM, Amit Gupta wrote: >> jv03: However, if you do, then document how the collectd smf service >> and collectdmon can (and can't) interact. In particular, in what >> ways >> can things go confusingly wrong if customer attempts to use both? >> The >> collectdmon man page is a good place to insert this information. >> > While collectdmon is not required if collectd is started via SMF, > there may be products which embed collectd and may want to manage > lifecyle of collectd via collectdmon.
That's fine if you feel there is value and wish to support it. The issue jv03 is about documenting to customers what to do and more importantly not do with it. i.e. customer starts collectd via smf and later attempts to also start it via collectdmon; what can go wrong? Same for reverse, run it via collectdmon and later 'svcadm enable' it as well, what happens? Or start it via collectdmon, get confused/forget and try to stop it via 'svcadm disable'. You can probably come up with other scenarios of weird things customer may do to confuse themselves. If we ship two separate mechanisms to do the same thing then we have a responsibility to the customer to give them some guidance on how things interact and what to do/not do. (Sure, the smart customer will know intuitively, pick one and don't mix and match. But documenting the advice formally is a good thing.) For the ARC case, I suggest two things: > Note that collectdmon is not require if collectd is started > via SMF. However, > there may be products which embed collectd and may want to > manage lifecyle of > collectd via collectmon. Add text here saying: "The man page will document that smf is the preferred mechanism and offer some guidance on the use of collectdmon on Solaris. Refer to Appendix 2 for more." Then add an Appendix 2 showing the text to add into the collectdmon man page. Probably just a paragraph or so. -- Jyri Virkki - jyri.virkki at sun.com .
