logo标签列表

systemctl，如何取消遮罩

systemd
root@gcomputer:~# systemctl status x11-common
● x11-common.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

我尝试过 systemctl unmask x11-common 和 systemctl unmask x11-common.service，但没有改变任何东西。
我应该如何取消掩码？
在我的情况下，文件已经被覆盖并且为空。 - chovy
4个回答
你正在使用的命令都是正确的。另请参阅手册。
当系统中除了指向/dev/null的符号链接之外没有现有的单元文件时，unmask命令似乎会失败。如果你mask一个服务，那么它会在/etc/systemd/system中创建一个指向/dev/null的新符号链接，systemd会在启动时在这个目录中查找要加载的单元文件。在这种情况下，实际上并不存在单元文件。 其他人似乎也遇到了类似的问题 在我的系统上，x11-common.service也被屏蔽了。你可以像这样修复它：
首先检查单元文件是否是指向/dev/null的符号链接。
file /lib/systemd/system/x11-common.service

应该返回：

/lib/systemd/system/x11-common.service: symbolic link to /dev/null

在这种情况下，删除它。
sudo rm /lib/systemd/system/x11-common.service

由于您更改了一个单元文件，您需要运行以下命令：

sudo systemctl daemon-reload

现在检查状态：
systemctl status x11-common

如果它没有显示"加载并运行"（如果圆圈仍然是红色的），请重新安装该软件包：
sudo apt-get install --reinstall x11-common

重新加载守护进程
sudo systemctl daemon-reload

再次检查状态
systemctl status x11-common

现在它是绿色的并且正在运行 :) 该服务没有systemd单元文件，但systemd愉快地使用位于/etc/init.d中的脚本。
好的，跟进问题：如果它甚至在您的系统上被掩盖了，那么这项服务是用来做什么的？如果对我们两个人都进行了掩盖，似乎它并不是真正需要的。 - Albert
@Albert 看这里，似乎该服务可以在没有systemd单元文件的情况下工作（它在/etc/init/目录下有一个文件...）。你可能想要提一个新问题。我所做的似乎没有明显的区别，只是服务显示为已加载、已启用、已停止（在启动时处于活动状态）（绿色），而不是已加载、已屏蔽、已停止（红色）。我应该阅读我的日志... - Zanna
如果有systemd的更新，单元文件将被重新安装，所以这并不是一个真正的结构性解决方案。 - hbogert
@hbogert即使没有单元文件，除了指向/dev/null的符号链接，这种情况也会发生吗？你对我的回答是正确的。我会将这个解决方案称为对systemd一个...令人困惑的行为...的一种变通方法。 - Zanna
你能否具体描述一下你所说的第一句话涉及到的文件，因为我对你所描述的情景并不是很理解。 - hbogert
@hbogert 在这种情况下，该服务无法被解除掩盖，因为它没有真正的单元文件，只是一个符号链接到 /dev/null 的位置，systemd在那里寻找具有适当名称的单元文件。我认为，在使用所描述的巧妙方法“修复”此类服务后，它将保持修复状态（即加载），而不受systemd更新的影响，但我不能完全确定 - 也许它会创建一个新的bitbucket符号链接，所以我想问问你是否知道。否则，我会在下一次systemd更新后自己检查。如果我说得不清楚，对不起，现在是睡觉时间了！ - Zanna
非配置文件在deb文件更新时总是被覆盖。我刚刚模拟了一个systemd的更新，/dev/null的符号链接被重新创建。 - hbogert
按照以下步骤进行：

  • systemctl edit systemd-hostnamed

    在编辑器中添加以下两行，然后退出（不要忘记在提示时保存）：

    [Service]
PrivateNetwork=no

  • 这将在以下目录中创建一个带有上述两行的override.conf文件：

    /etc/systemd/system/systemd-hostnamed.service.d/

  • 更新systemd：

    systemctl daemon-reload

  • 然后重新启动服务：

    systemctl restart systemd-hostnamed
    • 你现在应该能够运行hostnamectl而不会卡住了。
    这里我展示了如何使用systemctl来移除面具。
    $ sudo systemctl status bluetooth.service
● bluetooth.service
     Loaded: masked (Reason: Unit bluetooth.service is masked.)
     Active: inactive (dead)

$ sudo systemctl unmask bluetooth.service
Removed /etc/systemd/system/bluetooth.service.

$ sudo systemctl status bluetooth.service
● bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor preset: e>
     Active: inactive (dead)
       Docs: man:bluetoothd(8)

$ sudo systemctl start bluetooth.service

$ sudo systemctl status bluetooth.service
● bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor preset: e>
     Active: active (running) since Sat 2022-07-30 08:50:04 +06; 2s ago
       Docs: man:bluetoothd(8)
   Main PID: 23191 (bluetoothd)
     Status: "Running"
      Tasks: 1 (limit: 9135)
     Memory: 1.6M
     CGroup: /system.slice/bluetooth.service
             └─23191 /usr/lib/bluetooth/bluetoothd
    可能是您的服务存在一个空的覆盖文件，就像这样：
    ● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; masked; vendor preset: enabled)
  Drop-In: /etc/systemd/system/redis-server.service.d
           └─limit.conf

    检查limit.conf文件是否为空。如果是空的，请删除它。然后服务应该被解除屏蔽。
    我已经将我的操作添加到原始问题中。在屏蔽网络并重新启动系统后，接口没有启动。所以很明显是networkd在管理接口。我该如何确保由NetworkManager而不是networkd来完成这个任务？ - rajeev