Re: "returnszero" not working as expected

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
>>>> 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].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/53e1e3bb-c78f-411f-93bf-23574fa93747n%40googlegroups.com.