Re: "returnszero" not working as expected

Zander,

  The current value is '1048576' and the class 
'EN_NEEDS_CHANGE_SENDSPACE_en0' is set or is the valie different and the 
class is set?

Maybe add an `execresult` withour the option `-q` for grep as debug:
  * execresult("/usr/sbin/lsattr -El $(device) -a tcp_sendspace
       -F value | /usr/bin/grep 1048576", "useshell");

and print the result to see if it matches.

regards


On 05/09/2024 10:00, Xander Cage wrote:
> hmm...maybe just my brain is fishy...as i use returnszero in many other 
> promises and only this one is acting up i will check back.
> 
> but i guess you are right and its me who is out of touch a bit...
> 
> On Wednesday, September 4, 2024 at 5:25:55 PM UTC+2 
> [email protected] wrote:
> 
>     Hi Chris,
> 
>     I am wondering if I could ask about your original question. I don't
>     see a problem with the following. Given the promise:
> 
>         "EN_NEEDS_CHANGE_SENDSPACE_$(device)"   expression =>
>         returnszero ("/usr/sbin/lsattr -El $(device) -a tcp_sendspace -F
>         value | /usr/bin/grep -q 1048576", "useshell");
> 
>     Where device is en1 and the verbose output:
> 
>           verbose: returnszero ran '/usr/sbin/lsattr -El en1 -a
>         tcp_sendspace -F value | /usr/bin/grep -q 1048576' successfully
>         and it returned zero
>           verbose: Caching result for function 'returnszero("/usr/sbin/
>         lsattr -El $(device) -a tcp_sendspace -F value | /usr/bin/grep -
>         q 1048576","useshell")'
>           verbose: C:     +  Private class: EN_NEEDS_CHANGE_SENDSPACE_en1
> 
>         hmm...scratching my head...but i dont get it...it says the
>         command returned zero but the class is set.
> 
> 
>     So it would seem all is well. The command returns zero and so the
>     value given to the expression attribute is true aka "any" and should
>     cause the class to be defined.
> 
>     Also, when you ran Nick's example it seemed to act correctly.
> 
>     It's a bit hard to comment on the islessthan example since the value
>     of current_send_space_value is not given.
> 
>     What version of AIX are you running? And what is the default shell
>     aka what does `ls -l /bin/sh` give?
> 
>     Thanks!
>     -Craig
> 
>     On Wed, Sep 4, 2024 at 6:53 AM Xander Cage <[email protected]> wrote:
> 
>         i tried to use islessthan instead of returnszero...same
>         problem...something is fishy
> 
>         "EN_NEEDS_CHANGE_SENDSPACE_$(device)"  expression =>
>         islessthan($(current_send_space_value), "1048576");
> 
>         On Wednesday, September 4, 2024 at 7:54:23 AM UTC+2 Xander Cage
>         wrote:
> 
>             i am just guessing...the cached result contains the
>             unresolved instance of the "$(device)" variable and this command
>             is ran for every ethernet interface, might be that something
>             is overwritten here.
> 
>             verbose: C: BEGIN classes / conditions (pass 1)
>               verbose: returnszero ran '/usr/sbin/lsattr -El en0 -a
>             tcp_sendspace -F value | /usr/bin/grep -q 1048576'
>             successfully and it returned zero
> 
>               verbose: Caching result for function 'returnszero("/usr/
>             sbin/lsattr -El$(device) -a tcp_sendspace -F value | /usr/
>             bin/grep -q 1048576","useshell")'
>               verbose: C:     +  Private class:
>             EN_NEEDS_CHANGE_SENDSPACE_en0
> 
>             On Wednesday, September 4, 2024 at 7:28:41 AM UTC+2 Xander
>             Cage wrote:
> 
>                 hmm...your example works without any problems...
> 
>                 root@aixtest01: /root/cfe_testbed # /var/cfengine/bin/
>                 cf-agent -KI -f ./returnszero_issue.cf <http://
>                 returnszero_issue.cf>
>                 R: CFEngine 3.21.5 on aixtest01
> 
>                 R: The first returnszero() function evaluated true
>                 R: The second returnszero() function did not evaluate true
> 
>                 adding the action immediate also changes nothing...
> 
>                 i tried the commands in shell without cfengine...correct
>                 returncodes ...
> 
>                 root@aixtest01: /var/cfengine/inputs/itsv # /usr/sbin/
>                 lsattr -El en1 -a tcp_sendspace -F value | /usr/bin/grep
>                 -q 1048576; echo $?
>                 0
> 
>                 root@aixtest01: /var/cfengine/inputs/itsv # /usr/sbin/
>                 chdev -a tcp_sendspace=16256 -l en1
>                 en1 changed
>                 root@aixtest01: /var/cfengine/inputs/itsv # /usr/sbin/
>                 lsattr -El en1 -a tcp_sendspace -F value | /usr/bin/grep
>                 -q 1048576; echo $?
>                 1
> 
> 
> 
>                 On Tuesday, September 3, 2024 at 6:06:15 PM UTC+2
>                 [email protected] wrote:
> 
>                         Hi,
> 
>                         came across another weird thing…
> 
>                         i am running a command and setting a class on
>                         the return code…nothing special
> 
>                         EN_NEEDS_CHANGE_SENDSPACE_$(device)" expression
>                         => returnszero ("/usr/sbin/lsattr -El $(device)
>                         -a tcp_sendspace -F value | /usr/bin/grep -q
>                         1048576", "useshell");
> 
>                         until now, i was sure the class is set wenn
>                         return is 0…unfortunatly not in this case.
> 
>                         verbose output:
> 
>                         verbose: returnszero ran '/usr/sbin/lsattr -El
>                         en1 -a tcp_sendspace -F value | /usr/bin/grep -q
>                         1048576' successfully and it returned zero
>                         verbose: Caching result for function
>                         'returnszero("/usr/sbin/lsattr -El $(device) -a
>                         tcp_sendspace -F value | /usr/bin/grep -q
>                         1048576","useshell")' verbose: C: + Private
>                         class: EN_NEEDS_CHANGE_SENDSPACE_en1
> 
>                         hmm…scratching my head…but i dont get it…it says
>                         the command returned zero but the class is set.
> 
>                         if i do this it works as expected…
> 
>                         "EN_NEEDS_CHANGE_SENDSPACE_$(device)" not =>
>                         returnszero ("/usr/sbin/lsattr -El $(device) -a
>                         tcp_sendspace -F value | /usr/bin/grep -q
>                         1048576", "useshell");
> 
>                         i mean, i have no problem with setting it to
>                         "not", but an explaination of this reversed
>                         behaviour would be nice.
> 
>                         cfe version is 3.21.5, platform is aix
> 
>                     Hi Chris,
> 
>                     Can you create some simple standalone policy to
>                     demonstrate the differing behavior on different
>                     client versions on the same host?
> 
>                     For example, here is a very simple policy that is
>                     similar in nature to your snippet.
> 
>                     bundle agent __main__
>                     {
>                        classes:
>                          "RETURNSZERO_ECHO_PIPE_GREP_TRUE"
>                            expression => returnszero("/bin/echo hello | /usr/bin/grep -q el","useshell" );
>                          "RETURNSZERO_ECHO_PIPE_GREP_FALSE"
>                            expression => returnszero("/bin/echo hello | /usr/bin/grep -q NOPE","useshell" );
> 
>                        reports:
>                           "CFEngine $(sys.cf_version) on $(sys.fqhost)";
>                          RETURNSZERO_ECHO_PIPE_GREP_TRUE::
>                           "The first returnszero() function evaluated true";
>                          !RETURNSZERO_ECHO_PIPE_GREP_FALSE::
>                           "The second returnszero() function did not evaluate
>                     true";
>                     }
> 
>                     R: CFEngine 3.24.0a.fc037ae3b on precision-5570
>                     R: The first returnszero() function evaluated true
>                     R: The second returnszero() function did not evaluate true
> 
>                     Since there is a pipe in play in your example, I
>                     wonder if that is involved, perhaps a difference in
>                     which command is returning zero or not. Also,
>                     returnszero is a cached function, so your probe
>                     could be stale from start of the agent run, adding |
>                     action => immediate| to the promise should override
>                     caching for that promise.
> 
>         -- 
>         You received this message because you are subscribed to the
>         Google Groups "help-cfengine" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to [email protected].
>         To view this discussion on the web visit https://
>         groups.google.com/d/msgid/help-cfengine/92c08ea5-6369-41eb-
>         bc59-93ee76b64d30n%40googlegroups.com <https://
>         groups.google.com/d/msgid/help-cfengine/92c08ea5-6369-41eb-
>         bc59-93ee76b64d30n%40googlegroups.com?
>         utm_medium=email&utm_source=footer>.
> 
> 
> 
>     -- 
> 
>     	*Craig Comstock* (he/him) CFEngineer/Digger | CFEngine <https://
>     cfengine.com/>
>     Kansas, USA
>     <https://www.linkedin.com/company/northern.tech><https://
>     twitter.com/northerntechhq><https://northern.tech>	Northern.tech
>     <https://northern.tech> | Securing the world's connected devices
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to [email protected] <mailto:help- 
> [email protected]>.
> To view this discussion on the web visit https://groups.google.com/d/ 
> msgid/help-cfengine/53e1e3bb- 
> c78f-411f-93bf-23574fa93747n%40googlegroups.com <https:// 
> groups.google.com/d/msgid/help-cfengine/53e1e3bb- 
> c78f-411f-93bf-23574fa93747n%40googlegroups.com? 
> utm_medium=email&utm_source=footer>.

-- 
--
Bas van der Vlies
| High Performance Computing & Visualization | SURF| Science Park 140 | 
1098 XG  Amsterdam
| T +31 (0) 20 800 1300  | [email protected] | www.surf.nl |

-- 
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/ee8fbfef-1fc7-430c-96be-d0ca594893a6%40surf.nl.