"returnszero" not working as expected

[Xander Cage]

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

chris

[Nick Anderson]

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.

[Xander Cage]

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

[Xander Cage]

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

[Xander Cage]

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");

[Craig Comstock]

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

--
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 help-cfengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/92c08ea5-6369-41eb-bc59-93ee76b64d30n%40googlegroups.com.

--

Craig Comstock (he/him)
CFEngineer/Digger | CFEngine
Kansas, USA
Northern.tech | Securing the world's connected devices

[Xander Cage]

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...

[Bas van der Vlies]

Zander,

The current value is '1048576' and the class
'EN_NEEDS_CHANGE_SENDSPACE_en0' is set or is the valie different and the
class is set?

Maybe add an `execresult` withour the option `-q` for grep as debug:
* execresult("/usr/sbin/lsattr -El $(device) -a tcp_sendspace
-F value | /usr/bin/grep 1048576", "useshell");

and print the result to see if it matches.

regards

On 05/09/2024 10:00, Xander Cage wrote:
> 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
> craig.c...@northern.tech 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 -

>  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 <http://
> returnszero_issue.cf>

> 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 help-cfengin...@googlegroups.com <mailto:help-
> cfengine+u...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/

> msgid/help-cfengine/53e1e3bb-
> c78f-411f-93bf-23574fa93747n%40googlegroups.com <https://
> groups.google.com/d/msgid/help-cfengine/53e1e3bb-
> c78f-411f-93bf-23574fa93747n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

--
--
Bas van der Vlies
| High Performance Computing & Visualization | SURF| Science Park 140 |
1098 XG Amsterdam
| T +31 (0) 20 800 1300 | bas.van...@surf.nl | www.surf.nl |