Re: "returnszero" not working as expected

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/898dc601-b5a9-4d6c-a397-22516334b59cn%40googlegroups.com.