Re: "returnszero" not working as expected

Xander Cage <[email protected]> Tue, 3 Sep 2024 22:54:23 -0700 (PDT)
Newsgroups gmane.comp.sysutils.cfengine.general
Message-ID <[email protected]>
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/99e60bd0-4064-4a8c-ae86-00b9f1c29d0dn%40googlegroups.com.