[BUG] service.dead fails on system services on macOS

[lifanov]

Description
When unloading some services, launchd prints "Operation in progress." to stderr before
the unload completes. Salt interprets output on stderr as a failure even if return code is 0.
This is new behavior on macOS 10.15 and is not exhibited on 10.14 or previous versions.

Setup
Grab a mac with macOS 10.15 or newer.

Steps to Reproduce the behavior
Put below stanza into a state and run the state:

watchdog_service:
  service.dead:
    - name: /System/Library/LaunchDaemons/com.apple.watchdogd.plist

Expected behavior
Service is unloaded, state is successful.

Screenshots
If applicable, add screenshots to help explain your problem.

Versions Report

salt --versions-report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
           Salt: 3000.2
 
Dependency Versions:
           cffi: 1.12.2
       cherrypy: unknown
       dateutil: 2.8.0
      docker-py: Not Installed
          gitdb: 2.0.6
      gitpython: 2.1.15
         Jinja2: 2.10.1
        libgit2: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.19
       pycrypto: 3.8.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.5.4 (default, Apr 16 2020, 20:07:06)
   python-gnupg: 0.4.4
         PyYAML: 5.1.2
          PyZMQ: 18.0.1
          smmap: 3.0.2
        timelib: 0.2.4
        Tornado: 4.5.3
            ZMQ: 4.3.1
 
System Versions:
           dist:   
         locale: US-ASCII
        machine: x86_64
        release: 19.6.0
         system: Darwin
        version: 10.15.6 x86_64

Additional context
Even though the state correctly unloads the service, dependent states fail to execute because salt state is a failure.

[DmitryKuzmenko]

@lifanov thank you for the report. By quick look I've found no correlation between stderr and retcode that is used by salt to identify the proc run result. But it could be a timeout or something else. Could you please provide the minion debug log related to the issue?

[sagetherage]

@lifanov can you please provide the the minion debug log?

[garethgreenaway]

@weswhet @sheagcraig Any thoughts on this one? I believe we were talking about the service module not long ago.

[weswhet]

Well, there a few things. System Daemons are protected by System Integrity Protection. So if SIP is disabled then you may be able to use Salt to modify them.

Second, if SIP is disabled then this looks like a similar issue that is resolved in 3002.