Bash systemctl服务systemd notify不与非root用户一起工作

在Red Hat Enterprise Linux 7上，我有一个简单的服务单元和bash脚本示例，它使用

Type=notify

通知我正在尝试工作

当服务单元配置为以root用户身份启动脚本时，一切正常。添加

User=testuser

时失败。当脚本最初启动时（如流程列表上所示），

systemctl

服务从未收到指示就绪的通知消息，因此它将挂起并最终超时

[Unit]
Description=My Test
[Service]
Type=notify
User=testuser
ExecStart=/home/iatf/test.sh
[Install]
WantedBy=multi-user.target

Test.sh（由具有执行权限的testuser拥有）

当以root用户身份运行时，systemctl状态测试显示从my test.sh bash脚本发送的正确状态和状态消息。当

User=testuser

服务挂起，然后超时，并且

journalctl-xe

报告：

Jul 15 13:37:25 tstcs03.ingdev systemd[1]: Cannot find unit for notify message of PID 7193.
Jul 15 13:37:28 tstcs03.ingdev systemd[1]: Cannot find unit for notify message of PID 7290.
Jul 15 13:37:31 tstcs03.ingdev systemd[1]: Cannot find unit for notify message of PID 7388.
Jul 15 13:37:34 tstcs03.ingdev systemd[1]: Cannot find unit for notify message of PID 7480.

---

我不确定这些PID是什么，因为它们没有出现在ps-ef列表中

这似乎是

通知

服务类型中的已知限制

从a到

系统D

手册页

    Due to current limitations of the Linux kernel and the systemd, this
    command requires CAP_SYS_ADMIN privileges to work
    reliably. I.e. it's useful only in shell scripts running as a root
    user.

我尝试了一些针对

sudo

和朋友的黑客解决方法，但它们不会像

systemd

那样工作-通常会失败

No status data could be sent: $NOTIFY_SOCKET was not set

这指的是

systemd notify

试图向其发送数据的套接字-它在服务环境中定义，但我无法使其可靠地暴露在sudo环境中

您还可以尝试使用所描述的Python变通方法

它基本上只是一个不可靠的睡眠，而使用

notify

的关键是可靠的服务

---

在我的例子中，我刚刚重构为使用

root

作为用户，将实际服务作为主服务下的子服务，使用所需的用户sudo-u USERACCOUNT\u LOGGED notify send“hello”

在手册页中再也找不到这一点。这个问题解决了吗？

No status data could be sent: $NOTIFY_SOCKET was not set

python -c "import systemd.daemon, time; systemd.daemon.notify('READY=1'); time.sleep(5)"