resolves#12811 so-verify detects rare false error
If salt is uninstalled during call to so-setup where it detects a previous install, the "Failed" keyword from "systemctl stop $service" causes so-verify to falsely detect an installation error. This might happen if the user removes the salt packages between calls to so-setup, or if upgrading from Ubuntu 20.04 to 22.04 then installing 2.4.xx on top of a 2.3.xx installation.
The fix is to wrap the call to stop the service in a check if the service is running.
This ignores the setting of pid var, as the next use of pid is within a while loop that will not execute for the same reason the systemctl stop call was not launched in the background.
Instead of just existence, this checks if the directories are separate mountpoints when determining disk size and log_size_limit calculations.
It also sets the percentage to 80 if /nsm/elasticsearch is a separate mountpoint. This allows for better disk utilization on server configurations where /nsm is based on large slow HDDs for increased PCAP retention but /nsm/elasticsearch is based on SSDs for faster Elasticsearch performance.
This call to docker exec simply returns a number. No interaction (stdin) or tty is required. Specifically, having the -t option prevents running via salt using a command such as:
> salt '*' cmd.run 'so-redis-count'
using wait here instead of sleep tries to wait until pid 5 exits and generates the error
> /usr/sbin/so-playbook-reset: line 25: wait: pid 5 is not a child of this shell
PeteandGitHub