Permalink
Browse files

Use return code to determine service status in Upstart module.

This also broke the "dead" state.

This is because `service` will call `/etc/init.d/<service-name>` for
System V style services. Each of which could have different output.

For example:

    $ sudo invoke-rc.d exim4 stop
     * Stopping MTA                                               [ OK ]
    $ sudo service exim4 status
     * checking separate queue runner daemon...                   [ OK ]
     * checking combined SMTP listener and queue runner daemon... [ OK ]
    $ echo $?
    3
    $ sudo invoke-rc.d exim4 start
     * Starting MTA                                               [ OK ]
    $ sudo service exim4 status
     * checking separate queue runner daemon...                   [ OK ]
     * checking combined SMTP listener and queue runner daemon... [ OK ]
    $ echo $?
    0
  • Loading branch information...
1 parent 18b7cb7 commit f5cb036daab3c908fba60e783a8df3db6827da52 Tom Vaughan committed Apr 24, 2012
Showing with 1 addition and 1 deletion.
  1. +1 −1 salt/modules/upstart.py
View
@@ -221,7 +221,7 @@ def status(name, sig=None):
salt '*' service.status <service name>
'''
cmd = 'service {0} status'.format(name)
- return 'start/running' in __salt__['cmd.run'](cmd)
+ return not bool(__salt__['cmd.retcode'](cmd))
def _get_service_exec():

4 comments on commit f5cb036

Based on my usage, upstart status is returning true and causing this to think it is running when it isn't.

There needs to be better logic on this, at the very least make sure it is working for upstart as well as System V.

Owner

thatch45 replied May 1, 2012

I think that we might need some more serious auditing here, thanks for bringing it up

This at least restores the default behavior for Upstart jobs. #1161

Please sign in to comment.