目前我正在将我的Flask应用程序部署到Ubuntu服务器（AWS）。当我尝试启动uwsgi服务器并使用journalctl查看日志时，我发现了一种警告/错误。
我可以忽略它吗？我不知道如何解决它或它来自何处。现在坚持了2天。谁能帮我？
错误：
*** Operational MODE: preforking ***
Jan 04 15:27:11 ip-172-31-39-12 uwsgi[21781]: unable to load configuration from from multiprocessing.semaphore_tracker import main;main(10)
在我的情况下，此错误是由于使用uWSGI 2.0.17.1与Flask 1.0.2和scikit-learn 0.20.0。
在内部，scikit-learn导入joblib，在导入时尝试生成信号量跟踪过程（sklearn / externals / joblib / _multiprocessing_helpers.py）。
通过生成具有当前可执行文件名称的命令并从multiprocessing.semaphore_tracker import main; main（fd）“追加”-c'来生成信号量跟踪过程。
当前可执行文件的名称应该是'python'，但在使用uWSGI时则不是这样。结果命令是来自multiprocessing.semaphore_tracker import main的“/ usr / local / bin / uwsgi -c”; main（fd）“失败并输出上述错误消息。
解决方法，如here所述，是设置环境变量JOBLIB_MULTIPROCESSING = 0。
请注意，在我的情况下，唯一的结果是生成一个最终清理的已解散的uWSGI进程。
您正在尝试从应用程序内部（或从您正在使用的库中）生成子进程。据此，还产生了一个额外的协同进程 - 信号量跟踪器，负责将子进程创建的所有命名信号量返回给系统。这是一项重要的任务，因为如果命名的信号量被泄露（未删除），则关联的系统资源将被占用，直到下次重新启动。
系统具有有限数量的这些资源，因为它们位于共享存储器中。如果您确定应用程序使用的命名信号量不重要，则可以忽略此项。
请注意，多处理模块中定义的每种类型的锁定都是一个命名信号量。而且，multiprocessing.Queue，Barier等的每个实例都会实例化自己的锁。
例如，如果您正在生成许多进程（工作程序），并且每个进程都实例化多处理。锁定或多处理.RLock，泄漏（未删除）命名信号量的数量可能很大，快速耗尽限制，导致您的应用程序或其他人资源耗尽。
以下是对这些问题的解释的链接：https://docs.python.org/3/library/multiprocessing.html?highlight=semaphore%20tracker#contexts-and-start-methods
嘿，我一直在努力解决同样的问题，虽然我不知道如何实际阻止特定的信号量警告弹出更改我的一些uWSGI选项有助于改善问题。
我的.ini配置文件如下：
[uwsgi]
module = wsgi:app
master = true
processes = 16
socket = api.sock
chmod-socket = 660
vacuum = true
harakiri = 30
die-on-term = true
max-requests = 3
我做的补充是“harakiri”和“max-request”选项。 harakiri选项意味着如果请求的工作时间超过30秒，工作人员将自行回收，最大请求选项意味着工作人员将在三次请求后自行回收。这似乎是有效的，所以我的理论是，虽然信号量可能没有跟踪，但它们在某种程度上与工人联系在一起，并且定期回收它们可以提高性能。
这是内存泄漏的“愚蠢斗争”，我希望我有一个更优雅的解决方案，但过去几天一直在为我工作。祝好运！