service.status is broken under FreeBSD

[silenius]

Hello,

I think there is an issue with the service module under FreeBSD.

If PostgreSQL is not running on sandbox and that I execute (on the master):

salt sandbox service.status postgresql

it works as expected, it returns (on the master):

sandbox:
    False

However in the sandbox logs (the minion) the command returns with an ERROR:

2015-08-06 09:51:14,364 [salt.loaded.int.module.cmdmod            ][INFO    ][59556] Executing command '/usr/sbin/service postgresql onestatus' in directory '/'
2015-08-06 09:51:14,462 [salt.loaded.int.module.cmdmod            ][ERROR   ][59556] Command '/usr/sbin/service postgresql onestatus' failed with return code: 1
2015-08-06 09:51:14,462 [salt.loaded.int.module.cmdmod            ][ERROR   ][59556] output: pg_ctl: no server running

The problem is that /usr/sbin/service exits 0 only if the service is running and >0 otherwise:

root@sandbox:~ # service postgresql onestatus ; echo $?
pg_ctl: no server running
1
root@sandbox:~ # service postgresql onestart
LOG:  could not create IPv6 socket: Address family not supported by protocol family
LOG:  redirecting log output to logging collector process
HINT:  Future log output will appear in directory "pg_log".
root@sandbox:~ # service postgresql onestatus ; echo $?
pg_ctl: server is running (PID: 60256)
/usr/local/bin/postgres "-D" "/usr/local/pgsql/data"
0

I guess that some Salt code is checking for the exit status of the command and threats != 0 as an error ...

(Note that it breaks the service state too, it turns in an infinite loop)

[silenius]

it seems that replacing:

return not __salt__['cmd.retcode'](cmd, python_shell=False)

with:

return not __salt__['cmd.retcode'](cmd, python_shell=False, ignore_retcode=True)

in the status function of modules/freebsdservice.py fixes the problem, although I'm not sure if that's a proper solution ..

[silenius]

Also, maybe related to #24783

[jfindlay]

@silenius, thanks for the report. See also #18510.

[JaseFace]

Check out #23435 also, might want to merge any info into there.

[jfindlay]

Thanks @JaseFace. I forgot about that one. This looks like a duplicate of #23435.

[abednarik]

Hi @silenius

I made a Pr in order help fixing this. Check this if you have time.

Thanks

[terminalmage]

I'm not sure how this was ever "broken". It was returning the correct result. At worst it was just logging spurious errors.

[terminalmage]

The spurious logging is removed by #33294.