如何调试一个失败的systemctl服务（代码=已退出，状态=217/用户）？

Question

我正在尝试在 AWS/EC2 上添加我的第一个服务到 rhel7，但是服务未正确配置，因为我收到以下提示：

[ec2-user@ip-172-30-1-96 ~]$ systemctl status clouddirectd.service -l
● clouddirectd.service - CloudDirect Daemon
   Loaded: loaded (/usr/lib/systemd/system/clouddirectd.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: exit-code) since Tue 2018-01-09 16:09:42 EST; 8s ago
 Main PID: 10064 (code=exited, status=217/USER)

Jan 09 16:09:42 ip-172-30-1-96.us-west-1.compute.internal systemd[1]: clouddirectd.service: main process exited, code=exited, status=217/USER
Jan 09 16:09:42 ip-172-30-1-96.us-west-1.compute.internal systemd[1]: Unit clouddirectd.service entered failed state.
Jan 09 16:09:42 ip-172-30-1-96.us-west-1.compute.internal systemd[1]: clouddirectd.service failed.

还有：

[ec2-user@ip-172-30-1-96 ~]$ systemctl is-active clouddirectd
activating
[ec2-user@ip-172-30-1-96 ~]$ sudo systemctl list-units --type service --all | grep clouddirectd
  clouddirectd.service                                  loaded    activating auto-restart CloudDirect Daemon

我的单元文件是：

[ec2-user@ip-172-30-1-96 ~]$ cat /usr/lib/systemd/system/clouddirectd.service
[Unit]
Description=CloudDirect Daemon
After=network.target

[Service]
Environment=AWS_SHARED_CREDENTIALS_FILE=/etc/sonar/.aws/credentials
#ExecStart=/usr/lib/sonar/clouddirect/virtualenv/bin/python /usr/bin/sonar/clouddirectd -c /etc/sonar/clouddirect/clouddirectd.conf
ExecStart=/usr/lib/sonar/clouddirect/virtualenv/bin/python /usr/bin/clouddirect -c /etc/sonar/clouddirect.conf
# @PERM@ allow group write permission on newly created files
UMask=0007
#User=clouddirectd
User=clouddirect
Group=sonar
KillSignal=SIGINT
TimeoutStopSec=60min
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

你能否提供建议，如何调试这个systemctl服务，以便它不会一直崩溃和自动重启？

- boardrider

---

我知道我在你发布这个问题7个月后才回答，但你能告诉我这个答案是否适用于你的问题吗？ - JoshMc

你的回答，@JoshMc，方向正确（即用户名有问题）。 - boardrider

Boardrider，我注意到我的回答得到了许多赞同票，如果它符合您的问题，您是否介意接受它？我提到可能只是一个简单的拼写错误，我认为您在评论中指出了这一点。 - JoshMc

Answer 1

错误217表示服务在尝试启动时用户不存在。在您的情况下，服务中指定的用户是clouddirect。

 Main PID: 10064 (code=exited, status=217/USER)

Jan 09 16:09:42 ip-172-30-1-96.us-west-1.compute.internal systemd[1]: clouddirectd.service: main process exited, code=exited, status=217/USER

如果实际用户名错误（例如有拼写错误），或者该用户是外部用户存储（例如LDAP或Active Directory）的一部分，但需要启动的服务尚未启动，那么可能会导致此问题。例如，vasd.service 启动了一个产品，用于允许Linux对Active Directory进行身份验证，如果 vasd.service 没有启动，并且您指定的用户仅在Active Directory中可用，则需要在您的After=行中添加该服务。例如：

After=network.target vasd.service

- JoshMc

---

也许您是从另一台服务器复制了服务文件，但在此服务器上该用户不存在。 - lenko

像“/home/ec2-user/”这样带有连字符会出现问题吗？ - Steve Scott

我没有看到这是一个原因，你能否尝试使用没有嵌入连字符的用户，看看是否有所不同。 - JoshMc

Answer 2

这个问题有两个部分，一个是如何诊断217/USER错误，另一个是如何修复它。我将重点关注前者。

对于217/USER错误，这里有一些很好的指针：https://www.reddit.com/r/linuxquestions/comments/oaya49/systemd_service_not_starting_with_status217/ 217并不总是意味着它是用户问题，它只是表示它以217退出。可能是也可能不是...您可以使用journalctl查看哪些服务“似乎在它之后”最初启动或其他内容的日志。

系统启动期间可能还没有“网络用户”，您可以通过添加After=nss-user-lookup.target https://systemd.io/UIDS-GIDS/ 来解决此问题，但这里不是这种情况，因为它仍然在重新启动后失败，即稍后。systemd期望在服务启动时指定的用户“可用”。所以对于“系统用户”（早期运行进程），它们需要在本地机器上可用。对于稍后启动的进程，它们可以是“网络用户”。

您还可以尝试更改组和用户名（以及环境）为您“认为”systemd正在运行的内容，并手动运行它，看看会发生什么。 https://serverfault.com/questions/410577/execute-a-command-from-another-group有时希望systemd输出更多的调试信息，以便您可以更轻松地了解它正在运行什么...

在某些奇怪的情况下，您可能需要同时指定User =和Group =https://superuser.com/a/1452367/39364 在我们的情况下，“vintela status”运行时出现“SELinux可能未正确配置”的消息，确实，在禁用SELinux后，它开始按预期工作，不再出现217错误。[redhat 8]

- rogerdpack