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.