我有一个在 Raspberry Pi (Raspbian Buster) 上运行的自制婴儿监视器。监视器需要 2 个systemctl
服务才能运行:
- janus-stream.service:设置 GStreamer 管道以供 Jaanus Gateway 软件使用
- 剑锋服务:启动 Janus Gateway,促进 WebRTC 连接到流
在过去的某一时刻,我设置了这些服务,以便当 Pi 重新启动时,流会自动启动。但由于过去几个月的某种原因(不幸的是我不记得它是什么时候开始的),重新启动后,我在尝试访问流时收到此错误:No such mountpoint/stream 1
此错误显然源自 Janus Gateway 内部,并且解决这个问题的唯一方法是通过 SSH 连接到 Pi 并运行sudo systemctl restart janus.service
。我无法弄清楚为什么会发生这种情况或如何解决它以恢复优雅的启动行为。
有两种理论:
- 也许我的应用程序需要在之前和现在
janus-stream.service
运行,但这没有发生。janus.service
这可以解释丢失流错误。如果是这个问题的话如何保证这些服务的启动顺序? - 我不确定这是如何
systemctl
工作的,但几个月前当我尝试使用 Janus Gateway 的一些新功能时,我可能犯了一些错误,但此后我已将所有这些更改恢复到以前有效的状态。是否有可能systemctl
缓存了那些错误的 Janus Gateway 配置并在启动时运行这些配置而不是所需的命令?因此需要手动重新启动服务吗?
预先感谢您的任何帮助!
答案1
为了确保janus.service
在 后开始janus-stream.service
,[Unit]
的部分janus.service
还需要两行:
Wants=janus-stream.service
After=janus-stream.service
第一行指定janus.service
需要janus-stream.service
,但是它未指定启动顺序(有时这可能没问题,例如对于使用某些其他服务的服务,但仅在用户实际连接到该服务并执行某些特定操作之后)。
要指定所需的启动顺序,您还需要该After=janus-stream.service
行。
如果您使用Requires=
依赖项而不是Wants=
,它会产生副作用,如果无法满足依赖项,则导致整个启动操作被视为失败,从而有效地导致系统在启动时进入紧急模式(如果无法janus-stream.service
启动)...可能不是解决问题的最佳选择。
man systemd.unit
说:
通常,在处理失败的服务时,使用
Wants=
而不是为了实现更健壮的系统是更好的选择。Requires=
编辑完成后janus.service
,您应该运行systemctl daemon-reload
tellsystemd
来重新加载其配置和所有单元文件,以使您的编辑生效。