Re: "returnszero" not working as expected

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.