salt exit codes

[Deshke]

is there a reason why test.* returns False and exits with bash exit code 0 instead of 1 ?

~ # salt some-minion file.access  /var/run/reboot-required f; echo $?
<>:
    False
0

~ #  salt some-other-minion  file.access  /var/run/reboot-required f; echo $?
<>:
    True
0

[jfindlay]

Thanks for bringing this up, I believe the behavior you are seeing is the expected behavior. The command salt <minion> file.access is executed successfully in both cases, so the return value in both cases is 0, regardless of the result of the file.access function itself.

[Deshke]

hey, sorry. i would expect a different behavior, like if my test goes wrong, the return code should be 1 (http://tldp.org/LDP/abs/html/exitcodes.html) regardless if my salt command runs successfully.

salt <minion> file.file_exists /some/file/that/doesn't/exists ; echo $?
   False
0

salt <minion> file.file_exists /some/file/that/exists ; echo $?
   True
0

[jfindlay]

My reason for thinking a return of 0 was appropriate in this circumstance is that I am thinking of a return code as local to a system. Since salt runs successfully as intended on the master, it's return code would not be affected by the state of the remote minion. I admit that my reasoning on this is not very solid and am inclined to rather support your arguments.

A further consultation of the applicable standards as you have suggested is needed. I believe there is an issue somewhere about generally refactoring return statuses/return codes. I can't find it at the moment, but that ought to be referenced here.

[jfindlay]

Here it is: #7013.

[tjyang]

@jfindlay , thanks for the info on #7013. This bug should be classified above "Low Severity", IMO.

[jfindlay]

@tjyang, you're right. It seems that not all the return code issues were not resolved with #11337.

[jfindlay]

This is the plan for unifying and standardizing salt exit codes.

• salt beryllium:
  • Introduce a standard exit code enum-like data structure, probably somewhere in exitcodes.py such that integers and enums could be used interchangeably, but with enums being preferred within the source code.
  • Add a configuration option to enable the use of this new exit code standard by automatically evaluating the truthiness of the return value of the execution module functions and translating it into exit codes.
• salt boron: Ensure that all salt execution modules explicitly comply with
  the new salt exit code standard.

@thatch45, @cachedout, @basepi, or @UtahDave may have further commentary on this issue.

[inthecloud247]

+1

[simple10]

+1

[Oloremo]

Wait, what is the current status of retcodes for salt operations? It's been 4 years since the issue was created...

[terminalmage]

Exit codes have been normalized in #48361 for the upcoming Fluorine release. The following conditions will set a nonzero exit code:

• An exception is raised
• The code being run sets __context__['retcode'] to a nonzero value
• The return data for a given function is a dictionary with either a result or success key in it, which resolves as False

file.file_exists would not trigger any of those conditions, however. The problem here is if we use something like __context__['retcode'] in file.file_exists to denote failure, then we've marked the run as failed, so if any state invokesfile.file_exists, this would make salt reutrn a nonzero exit code even if the file not existing was expected (and therefore not an error).

[oliver-dungey]

I'm a bit confused about the status - I've just picked up salt 2018.3.4 which has the latest fixes in for return codes for salt-call. If I pass the argument --retcode-passthrough to salt-call I now get non-zero exit codes for failures but without it I always get 0 - is this the expected functionality at the current time? Anybody know when this functionality becomes the default?

[adubkov]

I think this is expected, as far as I know. To get status code from operation executed by salt-call you have to use --retcode-passthrough if nothing was changed.

[terminalmage]

@oliver-dungey As explained above, the retcode changes are in the Fluorine release (2019.2.0).

[terminalmage]

@saltstack/team-core Since Fluorine was released, this can be closed.

[dz-pyps]

Using salt version below, the issue with the incorrect exit code is still present when you add --batch-size and --batch-wait parameters

Salt Version:
           Salt: 2019.2.0
 
Dependency Versions:
           cffi: 1.6.0
       cherrypy: unknown
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: 0.6.4
      gitpython: 1.0.1
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: 0.26.3
        libnacl: Not Installed
       M2Crypto: 0.31.0
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.14
       pycrypto: 2.6.1
   pycryptodome: 3.7.3
         pygit2: 0.26.4
         Python: 2.7.5 (default, Apr  9 2019, 14:30:50)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: 0.9.0
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4

System Versions:
           dist: centos 7.6.1810 Core
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-957.5.1.el7.x86_64
         system: Linux
        version: CentOS Linux 7.6.1810 Core

sudo salt -v -L minion-1,minion-2 --batch-size 50% --batch-wait 1 state.apply queue=True test-state

Even though there is an error:

jid:
    20190613124535690469
retcode:
    1
gc-euw1-salt-1:
    Data failed to compile:
----------
    Rendering SLS 'base:test-state' failed: Jinja syntax error: expected token 'end of statement block', got 'string'; line 1

salt exit status is 0.

echo $?
0

[terminalmage]

Please open a new issue. Commenting on a closed issue doesn't do much good.