| Summary: | rc.subr fails to detect some python daemons | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Jason Wolfe <j> | ||||
| Component: | conf | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Closed Not A Bug | ||||||
| Severity: | Affects Some People | CC: | hrs, kbowling, python, sbruno | ||||
| Priority: | --- | ||||||
| Version: | 10.0-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
A coworker of mine found that this behavior is caused by py-setproctitle, which salt wraps the load of in a 'try'. At any rate, this means the proc title is the intended/actual that will be used, so this issue may start to affect others. py27-salt-2014.7.0_1 py27-setproctitle-1.1.8 I think this is an idiosyncrasy caused by a unique setproctitle invocation, so it's likely better addressed in the python code to append to the proc name, instead of prepend 'python2.7: ' in this case. Closing this. py-setproctitle is modifying the process name. This is the default format used by setproctitle, but we likely don't want to chose the iterations in rc.subr. |
Created attachment 151723 [details] rc.subr patch to detect new python proc format Salt for example causes a seemingly process odd format, possibly because of the way it invokes python: python2.7: /usr/local/bin/python2.7 /usr/local/bin/salt-minion -c /usr/local/etc/salt -d (python2.7) This format isn't picked up by rc.subr, so the daemon can't be manipulated. A simple patch is attached.