我有一个服务,我想在系统启动时启动它。我已经建立了ap@.service定义为模板,因为可能有许多实例。
在根systemd中定义,它运行良好,并启动和停止系统中的服务。正如预期的那样,服务实例安装有systemctl enable ap@inst1
。Root还可以毫无问题地启动和停止服务。该服务在其自己的帐户(myuser)中运行,而不是root,由ap@.service样板
但我希望用户"myuser"能够在不影响系统安全的情况下启动和停止自己的服务。
我切换到使用用户系统d,并使用loginctl enable-linger myuser
启用了延迟。然后,我启用在~myuser/.config/systemd/user目录中定义的服务。服务现在按照设计与系统一起干净地启动和停止。如果我以"myuser"的身份登录到终端,则systemctl --user start ap@inst1
和systemctl --user stop ap@inst1
都可以完美工作。
但是,如果我以不同的用户(user2)身份登录并在终端中执行sudo su - myuser
,那么systemctl --user
命令现在将失败,并显示错误消息"Failed to get D-Bus connection:no such file or directory"。
在sudo su - myuser
命令切换用户后,如何使systemctl --user
工作?
我在另一个网站上找到了答案,并使用不同的术语进行了进一步的搜索。
所需的解决方案是向shell提供信息,以便为用户找到正确的DBUS。
通过在运行systemctl --user
之前将以下环境变量添加到shell中,可以消除DBUS问题,并且systemctl可以正常运行。
export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
为了确保DBUS_SESSION_BUS_ADDRESS在sudo shell中可用,我将环境变量添加到目标userid的~/.bash_profile中。这需要创建登录外壳(sudo su - myuser
或sudo -l myuser
),以便创建正确的环境。
或者,将环境变量的创建添加到~/.bashrc(或其他shell的等效项)。然后将为所有的贝壳创造重新建立环境。
systemd 248(2021年3月发布)引入了对语法-M myuser@
的支持,用于指定另一个用户。
$ sudo systemctl --user -M myuser@ start ap@inst1
旁注:如果您想获得用户myuser的交互式登录外壳
$ sudo machinectl shell myuser@