[Xymon] adding a SVCS column for non-Windows clients?

[J.C. Cleaver]

On Tue, April 5, 2016 1:32 pm, Richard Hamilton wrote:
> Solaris 10 and later, and Mac OS X have a more or less similar* concept to
> Windows services: processes that are kept running by svc.startd (Solaris)
> or launchd (OS X).  It seems to me not unreasonable for them to report
> those in the same column, and to be able to use at least some of the  same
> syntax for the SVC line (status={started|stopped} only, since checking for
> the equivalent of startup= would be at best unduly tedious; i.e. neither
> svcs -a (Solaris) nor launchctl list (OS X) actually report whether the
> setting of a "service" is such that they'll be enabled at next reboot).
>
> Here's the thing: I'm not clear what actually evaluates the SVC expression
> against the client data; does that happen on the server, or on the client?
>
> In other words, what magic do I need to know to write a client-side script
> that will not only report the data, but do whatever its part of the job is
> in terms of either formatting it so the server can evaluate it, or so the
> client can obtain the configuration info from the server, as applicable?
>
> * I realize Windows services imply a bit more than just processes managed
> by the OS; but I don't think those differences are relevant to what I'd
> like to do.

Hi,

Unfortunately, at the moment that processing is done within the per-OS
client-type handling. To wit: only Windows boxes (BBWin or WinPS) are
analyzed for that section, so even if a compatiblly-formatted [svcs]
section is sent, it wouldn't be converted to a test. I don't think it
would be too difficult to patch that out into a more generic subsection,
but there may be distinctions between the Win and unix sides that need to
be kept.

I remember wanting to do something similar with chkconfig output a while
back for Linux, and there's probably useful analysis with systemd output
on the more recent ones.

In the short term, you can use the TEXT= values to give per-process
monitoring a more "service-y" feel for downstream users (as long as
there's a general mapping for services to procs)... this what we ended up
doing since there were only a few services we actually cared about.

The other alternatives) would be simply scripting your own test locally on
each box (easier), or -- if you need centrally manage -- writing a channel
processor to examine that section on all incoming client reports.


HTH,
-jc