我正在编写一个 python 脚本,将一些 MQTT 主题订阅到本地主机 MQTT 代理,当推送消息时,该脚本将调用同一目录中另一个脚本中的函数将更改加载到 SQL 数据库中。
在终端手动运行时,该脚本运行良好:
python3 /directory/path/to/file/listen_mqtt.py
但是,我试图让此文件在 Ubuntu 系统启动时自动执行。我在以下位置创建了一个新服务:
/lib/systemd/system/listen_mqtt_py.service
服务描述如下:
[Unit]
Description=Listen Mqtt
After=mosquitto.service
Wants=network.target
[email protected]
[Service]
Type=simple
ExecStart=/usr/bin/python3 /home/bt/dev/dexter-mqtt-to-sql/listen_mqtt.py
StandardInput=tty-force
[Install]
WantedBy=multi-user.target
我还启用了该服务并尝试使用以下命令启动该服务:
sudo systemctl enable listen_mqtt_py.service
和
sudo systemctl start listen_mqtt_py.service
重新启动机器并尝试手动运行服务时,我收到以下消息:
sudo systemctl status listen_mqtt_py.service
● listen_mqtt_py.service - Listen Mqtt
Loaded: loaded (/lib/systemd/system/listen_mqtt_py.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2020-11-17 13:45:28 AEDT; 14s ago
Process: 2206 ExecStart=/usr/bin/python3 /home/bt/dev/dexter-mqtt-to-sql/listen_mqtt.py (code=exited, status=1/FAILURE)
Main PID: 2206 (code=exited, status=1/FAILURE)
Nov 17 13:45:27 btdms systemd[1]: Started Listen Mqtt.
Nov 17 13:45:28 btdms systemd[1]: listen_mqtt_py.service: Main process exited, code=exited, status=1/FAILURE
Nov 17 13:45:28 btdms systemd[1]: listen_mqtt_py.service: Failed with result 'exit-code'.
我做了一些研究,发现这种错误可能与在加载某些所需设备之前过早调用服务有关。因此,我尝试将 改为After=
并将network-online.target
改为mosquitto.service
,但没有成功,服务仍然退出并显示相同的错误消息。
因为即使我手动运行,该服务也无法完全执行sudo systemctl start listen_mqtt_py.service
,所以我怀疑这不是由于其他服务未及时加载。这是其他原因。但我不明白为什么。
如果需要的话我也很乐意发布 Python 脚本listen_mqtt.py
。
谢谢。
答案1
事实证明,这是由于用户对 Python 包的权限所致。可以找到诊断此问题的方法这里。
让我们找出启动失败的 systemd 服务
$ systemctl --failed
发现 systemd-modules-load 服务存在问题。我们想了解更多信息。
$ systemctl status systemd-modules-load
如果需要重新生成失败消息,请重新启动服务
$ systemctl restart systemd-modules-load
现在获得了 PID:
journalctl _PID=15630
或者
journalctl _SYSTEMD_UNIT=systemd-modules-load.service
您应该能够看到失败时生成的错误消息。查看错误消息,我们知道包paho
未正确导入。
解决方案
a. 使用 root 安装相关的 python 包(我最终就是这么做的)
进入 root CLI
sudo su -
b. 为服务中所需的 Python 包授予 root 权限,我没有这样做,因为我不确定它对其他用户的行为方式,也不确定 root 是否需要比仅包更多的权限。可以找到有关此问题的讨论这里。
答案2
journalctl -u charge_check.service -b 检查出了什么问题