☰

CentOS 8 上的 systemd 守护进程内部屏幕

tag-icon • tag-icon systemd gnu-screen daemon chmod centos8
CentOS 8 上的 systemd 守护进程内部屏幕

所以我想在 systemd 服务中运行屏幕这样我就可以在进程（守护进程内部）运行时向其发出命令。请参阅问题末尾的示例，了解我希望能够做什么。

我目前拥有的： 一个 Java 应用程序，以 -running 作为守护进程启动，
ExecStart=/usr/bin/java -someArguments -jar server.jar并将 user:group 设置为 "server":"server"，以及 "ProtectSystem=full" 和类似的强化参数。它运行良好，没有问题。

但是，我想要： 与上面相同，但它在屏幕实例内运行。如下所示：
ExecStart=/usr/bin/screen -DmS aServer /usr/bin/java -someArguments -jar server.jar

后者拒绝启动，输出journalctl -xe告诉我：“无法执行命令：权限被拒绝”。但是，如果我自己在终端中执行此操作（与 ExecStart 中的命令相同），我可以从同一用户（服务器：服务器）启动屏幕会话。

我在网上找到了一个解决方案，上面说：
# Uncomment this to fix screen on RHEL 8
ExecStartPre=+/bin/sh -c 'chmod 777 /run/screen'

但是我本能地不喜欢 777 这个部分，而且我不明白为什么它需要在每次守护进程启动时运行。

我基本上想问的是：如何让屏幕在 systemd 守护进程中工作？上述解决方案是一个好主意吗，还是有更好的方法？

我想做的事情的例子：

  1. 有一个 systemd 计时器，其序列中有ExecStartPre=/screen -p 0 -S -X eval 'stuff "save-all"\\015'（或类似）。
  2. ExecStop 期间的一系列命令，如上所示。
  3. 当我手动连接到 Linux 服务器（连接到屏幕实例）时能够与该过程进行交互。

答案1

要在 Linux 中将基于 Java 的服务器作为守护进程运行，您可能需要了解 Apache Tomcat 之类的程序是如何配置的。

它以一个名为的服务开始/etc/systemd/system/tomcat.service

# Systemd unit file for tomcat
[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target

[Service]
Type=forking

Environment=JAVA_HOME=/usr/lib/jvm/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID

User=tomcat
Group=tomcat
UMask=0007
RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

请注意，您的服务器将由脚本中的命令启动/opt/tomcat/bin/startup.sh

然后你可以执行如下命令：

sudo systemctl daemon-reload

sudo systemctl start tomcat

sudo systemctl status tomcat

答案2

抱歉回复迟了，我确实发现并解决了这个问题。

此问题源于基于 RHEL8 的操作系统上的 SELinux 配置。

由于安装位置的原因，守护进程内的屏幕在 centos8 上被 SELinux 阻止（可能还有 Rocky Linux，或 RHEL 8 的其他衍生产品）。如果我理解正确的话，有一些 SEL 策略阻止守护进程在 /usr/bin/ 中执行程序。不幸的是，我不记得在哪里偶然发现了这些信息。

一个解决方案是安装屏幕后将其复制到其他位置，如/usr/local/bin。复制可执行文件后，确保将其所有权设置为，root:screen并将权限设置为-rwxr-xr-x (chmod 755)。

然后只需从新位置执行屏幕：

ExecStart=/usr/bin/screen -DmS aServer /usr/bin/java -someArguments -jar server.jar

不需要（不要做）任何chmod 777，ExecStartPre=+ ...或类似的降低安全性的解决方案。

另一种解决方案方法是使用 SEL 的 audit2allow 功能，首先在 中找到被阻止的屏幕报告/var/log/audit/audit.log，然后使用条目的标识名称（例如name=something），然后将其发送到 audit2allow，如下所示：

grep 'screen-or-other-name-found' /var/log/audit/audit.log | audit2allow -M screen-inside-daemon

semodule -i screen-inside-daemon.pp

这应该会创建一个允许设置工作的 SELinux 策略。通过运行以下命令进行验证：semodule -l | grep screen-inside-daemon并测试服务。

我还没有测试过后一种方法，而且我不再有任何包含此问题日志的实例，因此 audit.log 条目的名称未指定。

相关内容