Systemd 提供了许多工具用于查看系统启动情况，也可以控制在系统启动时运行什么。
Systemd 类发行版中如何关闭一些令人讨厌的进程呢？
查看开机启动项
通过查看 /etc/init.d 了解到哪些服务进程会在引导时启动。
Systemd 以不同的方式展现，可以使用如下命令罗列允许开机启动的服务进程：
$ systemctl list-unit-files --type=service | grep enabled
accounts-daemon.service enabled
anacron-resume.service enabled
anacron.service enabled
bluetooth.service enabled
brltty.service enabled
[...]
蓝牙服务是冗余项，不需要使用蓝牙功能，故无需运行此服务。
停止该服务进程，并且使其开机不启动：
$ sudo systemctl stop bluetooth.service
$ sudo systemctl disable bluetooth.service
可以通过下面命令确定是否操作成功：
$ systemctl status bluetooth.service
bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor
preset: enabled) Active: inactive (dead)
Docs: man:bluetoothd(8)
停用的服务进程仍然能够被另外一个服务进程启动。如果真的想在任何情况下系统启动时都不启动该进程，无需卸载该它，只需要把它掩盖起来就可以阻止该进程在任何情况下开机启动。
$ sudo systemctl mask bluetooth.service
Created symlink from /etc/systemd/system/bluetooth.service to /dev/null.
一旦对禁用该进程启动而没有出现负面作用感到满意，也可以卸载该程序。
通过执行命令可以获得如下服务列表：
$ systemctl list-unit-files --type=service
UNIT FILE STATE
accounts-daemon.service enabled
acpid.service disabled
alsa-restore.service static
alsa-utils.service masked
不能启用或禁用静态服务，因为静态服务被其它的进程所依赖，并不意味着它们自己运行。
哪些服务能够禁止？
如何知道需要哪些服务，而哪些又是可以安全地禁用的呢？
许多服务进程都是发行版特定的，所以应该看看发行版文档。
accounts-daemon.service 是一个潜在的安全风险。它是 AccountsService 的一部分，AccountsService 允许程序获得或操作用户账户信息。不认为有好的理由能使我允许这样的后台操作，选择掩盖 mask 该服务进程。
avahi-daemon.service 用于零配置网络发现，使 PC 发现网络中的打印机或其它主机，禁用。
brltty.service 提供布莱叶盲文设备支持，如：布莱叶盲文显示器
debug-shell.service 开放了一个巨大的安全漏洞（该服务提供了一个无密码的 root shell，用于帮助调试 systemd 问题），除非正在使用该服务，否则永远不要启动服务。
ModemManager.service 该服务是一个被 dbus 激活的守护进程，用于提供移动宽频 broadband（2G/3G/4G）接口，如果没有，无论是内置接口，还是通过如蓝牙配对的电话，以及 USB 适配器，那么也无需该服务。
pppd-dns.service 是一个计算机发展的遗物，如果使用拨号接入互联网，保留它，否则不需要。
rtkit-daemon.service 听起来很可怕，听起来像是 rootkit。但是需要该服务，因为它是一个实时内核调度器 real-time kernel scheduler。
whoopsie.service 是 Ubuntu 错误报告服务。它用于收集 Ubuntu 系统崩溃报告，并发送报告到 https://daisy.ubuntu.com 可以放心地禁止其启动，或者永久的卸载它。
wpa_supplicant.service 仅在你使用 Wi-Fi 连接时需要。
系统启动时发生了什么？
Systemd 提供了一些命令帮助调试系统开机启动问题。该命令会重演系统启动的所有消息。
$ journalctl -b
-- Logs begin at Mon 2016-05-09 06:18:11 PDT,
end at Mon 2016-05-09 10:17:01 PDT. --
May 16 06:18:11 studio systemd-journal[289]:
Runtime journal (/run/log/journal/) is currently using 8.0M.
Maximum allowed usage is set to 157.2M.
Leaving at least 235.9M free (of currently available 1.5G of space).
Enforced usage limit is thus 157.2M.
[...]
journalctl -b -1 可以复审前一次启动
journalctl -b -2 可以复审倒数第 2 次启动，以此类推。
该命令会打印出大量的信息，可能并不关注所有信息，为此，系统提供了几个过滤器，用于帮助锁定目标。以进程号为 1 的进程为例，该进程是所有其它进程的父进程。
$ journalctl _PID=1
May 08 06:18:17 studio systemd[1]: Starting LSB: Raise network
interfaces.... May 08 06:18:17 studio systemd[1]: Started LSB: Raise
network interfaces.. May 08 06:18:17 studio systemd[1]: Reached target
System Initialization. May 08 06:18:17 studio systemd[1]: Started CUPS
Scheduler. May 08 06:18:17 studio systemd[1]: Listening on D-Bus System
Message Bus Socket May 08 06:18:17 studio systemd[1]: Listening on CUPS
Scheduler. [...]
这些打印消息显示了什么被启动，或者是正在尝试启动。
一个最有用的命令工具之一：systemd-analyze blame
用于帮助查看哪个服务进程启动耗时最长
$ systemd-analyze blame
8.708s gpu-manager.service
8.002s NetworkManager-wait-online.service
5.791s mysql.service
2.975s dev-sda3.device
1.810s alsa-restore.service
1.806s systemd-logind.service
1.803s irqbalance.service
1.800s lm-sensors.service
1.800s grub-common.service
这个特定的例子没有出现任何异常，但是如果存在系统启动瓶颈，则该命令将能发现它。
No comments:
Post a Comment