questdb.sh stop and status options fail to find pid on FreeBSD using ps -ef

[hraftery]

Describe the bug

Running questdb.sh status -d path/to/root/dir or questdb.sh stop -d path/to/root/dir returns "Not running", even when QuestDB has been started with questdb.sh start -d path/to/root/dir and is running, as evidenced by a listing in the process table and a functional web console.

Closer inspection reveals that both commands call "export_pid" which uses ps -ef to find the process. On FreeBSD this command returns truncated output that does not necessarily contain the process label. The equivalent on FreeBSD to the Linux ps -ef is ps auwwx. Modifying "export_pid" to use that command instead results in expected behaviour (see Additional context below).

To Reproduce

• Fresh instance of FreeBSD 12.2-RELEASE-p1
• Fresh download of questdb-6.0.4-rt-freebsd-amd64
• Install bash with pkg install bash since it is (unexpectedly) required by questdb.sh
• Run questdb-6.0.4-rt-freebsd-amd64/bin/questdb.sh start
• Run questdb-6.0.4-rt-freebsd-amd64/bin/questdb.sh status
• Run questdb-6.0.4-rt-freebsd-amd64/bin/questdb.sh stop

Expected behavior
What happens when I fix the export_pid function. That is status reports the PID, and stop ends the process.

Screenshots
N/A

Environment (please complete the following information):

• OS: FreeBSD 12.2-RELEASE-p1
• Browser: N/A
• Version: questdb-6.0.4

Additional context

A potential diff that fixes this issue is:

41a42,50
> case `uname` in
>    FreeBSD)
>        export PS_CMD="ps auwwx"
>        ;;
>    *)
>        export PS_CMD="ps -ef"
>        ;;
> esac
> 
66c75
<     export QDB_PID=`ps -ef | grep ${QDB_PROCESS_LABEL} | grep -v grep | tr -s " " | cut -d " " -f ${PID_FIELD}`
---
>     export QDB_PID=`${PS_CMD} | grep ${QDB_PROCESS_LABEL} | grep -v grep | tr -s " " | cut -d " " -f ${PID_FIELD}`

[hraftery]

By the way, I should say that the "potential diff" I've provided is probably not a great solution. Given that "Darwin" is a BSD, the two cases should probably be merged.

[ideoma]

Thanks for the issue and fix suggestion @hraftery,
If you don't mind a pull request with the fix would be really appreciated. FreeBSD is on the exotic side for the team at the moment.

[hraftery]

Okay, willing to give it a go, but note it's difficult for me to test well across OS's. PR submitted. Tested in my personal Darwin environment as a mitigation against silly regressions, but not much beyond that.

[bsmth]

This should be fixed as of #1282 - thanks @hraftery !