跟 systemd 还是脱不开干系，虽然 95% 的错大概在我身上啦……

前文在这儿。

Yesterday Once More

总之，又是同样的事件，同样的查错方式，同样的 workaround 也正常工作，直到我发现了 systemd-userdbd 和 userdbctl：

$ userdbctl user kotono
   User name: kotono
 Disposition: dynamic
    Login OK: no (record is locked)
 Password OK: no (none set)
         UID: 1000
         GID: 1000 (kotono)
 Aux. Groups: wheel
   Real Name: Dynamic User
   Directory: /
     Storage: classic
       Shell: /usr/bin/nologin
      Locked: yes
   Passwords: none
     Service: io.systemd.DynamicUser

等会，什么是 Login OK: no？

啊？

看到 Dynamic User 又想了一会之后才发现，这可能是之前一个服务配置的问题。

我有一段这样的 systemd 服务定义：

# 前略

[Service]
Type=simple
User=kotono
DynamicUser=yes

# 后略
conf

把 DymanicUser=yes 删掉之后重启服务就好了（又另外配置了一些 ProtectSystem= 什么的）。

所以是为什么？

systemd.exec 的 man 文档这么说：

If a statically allocated user or group of the configured name already exists, it is used and no dynamic user/group is allocated.

也就是说，如果 User= 和 DynamicUser=yes 同配，User= 指定的用户会作为 DynamicUser，这大概就是 shadow 上我的帐号可以正常使用但 systemd 偏不这么认为的原因——它认为我的帐号是 Dynamic User！

今天的一课：DymanicUser= 和 User= 同用可能存在副作用，会在 systemd 层面上影响 User= 所指的账户登录。