#24 include directive needs precedence


As it is, if I add in an include directive
(include_checks.$HOST for instance), and both the
uxmon-net and the included file contain the same
variable with a different value, both are used, and
neither the included file or the uxmon-net takes
precedence (but the lowest threshold takes precedence).

Consider the following:

localhost sshd(1-5) procs

localhost sshd(1-20) procs

Since uxmon-net is a generic default file (or should
be, since I wouldn't want to customize this
specifically for each host), the include file should
theoretically take precedence. In this case, in
general I don't want to see more than 5 sshd's running
anywhere, but in the exception
(included_checks.$HOST) I want to allow up to 20 sshd

Is there another way to easily accomplish this?



  • Thomas Aeby

    Thomas Aeby - 2001-06-19

    Logged In: YES

    uxmon-net is always "additive", so if you specify

    something like

    myhost procs=sshd(1-5) procs

    myhost procs=sshd(4-8) procs

    you actually set up two "procs" test, one testing the

    number of sshd being in the range 1..5, one testing

    against the range 4..8. You will get two results

    reported under myhost.procs and actually myhost.procs

    will get red if the number of sshd processes is higher

    than 5 or lower than 4 (the status of myhost.procs is

    the "worst" status of all the tests reporting as


    At the moment I do not see any better way how uxmon

    could interprete uxmon-net ... how will it know if

    you need multiple procs tests or if one should override

    the other, though I see your point there - it would be

    nice to have a valuable set of standard tests in a

    general uxmon-net file being the same on every agent and

    override some specific tests on some specific hosts.

    I haven't got any solution ready. We have to solve this

    kind of problem with the new config format.

    Best regards,


  • Thomas Aeby

    Thomas Aeby - 2001-06-19
    • status: open --> open-wont-fix
  • Derek Douville

    Derek Douville - 2001-06-22

    Logged In: YES

    I think I have a solution which I'll program and test.
    The include directive will be as follows:

    include filename_$HOST [-optional flags,-optional flags...]

    Thus in uxmon-net, which can now set the default for
    everything, the customizations can be maintained as

    include additives_$HOST -additive (default, as it is now)
    include myoverrides_$HOST -priority (replicated values
    override uxmon-net entries)
    include myoverrides_$HOST -submissive (gives way to
    uxmon-net defaults)
    include mystuff_$HOST -iflower (only overrides variables if
    threshholds in mystuff_$HOST are lower than uxmon-net)
    include mythings_$HOST -ifhigher (only override variables if
    threshholds in mythings_$HOST are higher than uxmon-net).

    Can I please get comments on the above? This can probably
    to simplified or clarified. Your input is appreciated.
    I'll work on the priority and submissive options and see how
    it works.

    The second thing I'm going to try to add is support for host
    Classes (so you can do 'include myfile_$CLASS') which will
    match against a configuration file of hosts, or a hostname
    template. If you have meaningful hostnames with patterns,
    it would be useful. For instance:

    if (/(www)[0-9]+/$1/) {
    $CLASS = $1;
    include mywebservers_$CLASS

    (consider the above pseudo code).

    Alternatively, $CLASS can be defined in a file, or in XML
    format (my ultimate site management goal).

    Ideas here also appreciated.

  • Thomas Aeby

    Thomas Aeby - 2001-06-24

    Logged In: YES

    In my eyes this is the wrong way to go. The way the current
    uxmon-net configuration works is incompatible with this
    idea. If you have configured two "things" like

    m1 procs=whatever procs
    m1 procs=whateverelse procs

    this always will be treated as two independent tests
    uxmon has to run against m1. I don't like the idea
    that includes is doing more than just copy in a file.
    With the current model one could do some dirty tricks
    using the "DEFAULT" mechanism ...

    No matter what I think about the suggested solution
    your needs and the way you would like to have them
    fulfilled is something we should not ignore! I would
    appreciate if you could have a look at the feature
    request (see Tracker/Feature Requests) about the new
    uxmon configuration format we are discussing about.
    I am sure your position would bring us a step forward!

    Best regards,

  • Thomas Aeby

    Thomas Aeby - 2001-06-28

    Logged In: YES

    I close this and assume we will solve the issues when
    moving to a new config file format.

  • Thomas Aeby

    Thomas Aeby - 2001-06-28
    • status: open-wont-fix --> closed-wont-fix

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks