Document that service.running uses service <service> status and interprets by return code

[cupdike]

salt 2014.1.10 (Hydrogen) on Redhat 6.5

Doing a service 'running' state, I expect it to start an "ambari-server" service. But salt thinks the service is running and does not start it. Here, the service module's status function demonstrates the problem. Both ps and a service status show it is not running, but service.status returns True:

-bash-4.1$ sudo service ambari-server status
Using python  /usr/bin/python2.6
Ambari-server status
Ambari Server not running. Stale PID File at: /var/run/ambari-server/ambari-server.pid
-bash-4.1$ ps -ef | grep ambari-server
501       7688  2927  0 17:17 pts/0    00:00:00 grep ambari-server
-bash-4.1$ sudo salt-call --local service.status ambari-server
[INFO    ] Executing command '/sbin/service ambari-server status' in directory '/root'
[INFO    ] output: Using python  /usr/bin/python2.6
Ambari-server status
Ambari Server not running. Stale PID File at: /var/run/ambari-server/ambari-server.pid
local:
    True

Perhaps the stale pid file message is at play. But when I run the OS command that is being logged, it looks like it should work so I'm not sure where salt is making the final determination that it's running:

[INFO    ] Executing command "ps -efH | grep 'ambari-server' | grep -v grep | fgrep -v status.pid | awk '{print $2}'" in directory '/root'

# Trying that command...
-bash-4.1$ ps -efH | grep 'ambari-server' | grep -v grep | fgrep -v status.pid | awk '{print $2}'
-bash-4.1$ 

-bash-4.1$ salt --versions-report
           Salt: 2014.1.10
         Python: 2.6.6 (r266:84292, Nov 21 2013, 10:50:32)
         Jinja2: unknown
       M2Crypto: 0.20.2
 msgpack-python: 0.1.13
   msgpack-pure: Not Installed
       pycrypto: 2.0.1
         PyYAML: 3.10
          PyZMQ: 2.2.0.1
            ZMQ: 3.2.4

[basepi]

Hrm, strange, we'll definitely investigate this.

[cupdike]

I think what is going on is that salt is relying on the exit code to the service call to determine if the service is running. If I hack the call to service ambari-server status to return 1 when the service is not running, salt starts recognizing the correct status of the service:

bash-4.1$ sudo service ambari-server status && echo "status was 0" || echo "status was 1"
Ambari Server not running. Stale PID File at: /var/run/ambari-server/ambari-server.pid
status was 1
-bash-4.1$ sudo salt-call --local service.status ambari-server
[INFO    ] Executing command '/sbin/service ambari-server status' in directory '/root'
[ERROR   ] Command '/sbin/service ambari-server status' failed with return code: 1
[ERROR   ] output: Ambari Server not running. Stale PID File at: /var/run/ambari-server/ambari-server.pid
local:
    False
-bash-4.1$ sudo service ambari-server start
...snip
-bash-4.1$ sudo salt-call --local service.status ambari-server
[INFO    ] Executing command '/sbin/service ambari-server status' in directory '/root'
[INFO    ] output: Ambari Server running
Found Ambari Server PID: '13701 at: /var/run/ambari-server/ambari-server.pid
local:
    True

I'm guessing this would not be considered an issue with Salt--but I leave you to disposition this as you see fit. Maybe the docs could mention the requirement that the service returns the correct status code (sorry if I missed that).

Anyway, I will take the non-conformance up with the ambari folks. Sorry for not figuring it out before filing it...

[basepi]

Interesting. Good catch. I am going to mark this as an upstream bug, but you're right, we definitely need to put a note in the docs noting that we interpret success by return code.

[basepi]

I changed my mind, I'm going to just utilize this issue for the documentation.

[cupdike]

This link covers the expected status code from an init script status, which might be useful for the documentation:

http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

[basepi]

Awesome, thanks for adding that.

[twellspring]

Fixed in documentation by #19877

[basepi]

Awesome, thanks @twellspring!

[scott-edwards-123]

Thanks for documenting this @twellspring & @cupdike. I've been running into the same problem.