Title: "processes:: ... matches=[n] ... elsedefine=" not working for exact matches?

I recall running into this about a year or so ago, and don't seem to have reported or resolved this.  I'm having an issue where elsedefine is not set, even though the processes stanza identifies the mismatch and issues a warning... but only apparently if I'm using the exact match (logical == equivalent).  When using a less-than or equal to (logical <=) or (>=) equivalents the condition is set and elsedefine is created.

I'm running a 2.1.16 server, and 2.1.13 clients, both x86_64 arch.  Seems like an obvious bug, and I think it's been around for a while.  Perhaps it's been fixed recently, but don't seen any indication... even cfwiki has it up on the wishlist :) "http://cfwiki.org/cfwiki/index.php/Wishlist"  I've been meaning to add a wishlist item for switching over to "normal" operator order (i.e. reversing that which is used :) but am sure it won't happen.


Works:
  "/usr/sbin/automount" matches=>0
    elsedefine=autofs_restart

  "/usr/sbin/automount" matches=<7
    elsedefine=autofs_restart

Borks:
  "/usr/sbin/automount" matches=6
    elsedefine=autofs_restart

Any suggestions on resolving it, version in which it is fixed, patches, etc?

Cheers,

/eli

_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
http://cfengine.org/mailman/listinfo/help-cfengine

Reply via email to