When devel/py-setproctitle is installed as a dependency of another software, it will cause salt minion to adjust its process title from (python3.8 case)
2539 0 /usr/local/bin/python3.8 /usr/local/bin/salt-minion -c /usr/local/etc/salt -d
8656 0 python3.8: /usr/local/bin/python3.8 /usr/local/bin/salt-minion -c /usr/local/etc/salt -d KeepAlive MultiMinionProcessManager MinionProcessManager (python3.8)
the rc.d script, using "command_interpreter", cannot assert the running state of the minion and when used together in a combination with a process pacemaker (puppet, monit etc) will cause numerous copies of the minion running.
Using "procname" instead of "command_interpreter" in the rc.d script fixes this.
Could you include the relevent files contents (as attachments) before and after installing setproctitle that shows the changes in invocation lines.
Also, I can't see setproctitle as an unconditional or OPTION'al dependency for the salt port. How/where/when is setproctitle being introduced? Can you provide minimal steps to reproduce
Created attachment 226058 [details]
change use of command_interpreter in procname for rc.d files
This is a proposed patch to let the rc.d files for the sysutils/py-salt port to continue to work when devel/py-setproctitle is present on the system.
the one for files/salt_proxy.in is subject to debate though as it clashes with the style of using procname to start a script. having both command_interpreter and procname doesn't work.
(In reply to Kubilay Kocak from comment #1)
I see two things,
I happen to have netbox installed on the same system as the salt minion, and net-mgmt/netbox installs devel/py-setproctitle as a indirect dependency through www/py-gunicorn.
I also see setproctitle as a dependency in salt's requirement files themselves, but is apparently happy to work without it:
$ grep -rl setproctitle work-py38/salt-3003.1/requirements/ | grep freebsd
so it could be added as a run dependency too