如何對Linux系統開機啟動項進行清理
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
你不能啟用或禁用靜態服務，因為靜態服務被其他的進程所依賴，并不意味著它們自己運行。
哪些服務能夠禁止?
如何知道你需要哪些服務，而哪些又是可以安全地禁用的呢?它總是依賴于你的個性化需求。
這里舉例了幾個服務進程的作用。許多服務進程都是發行版特定的，所以你應該看看你的發行版文檔(比如通過 google 或 StackOverflow)。
- accounts-daemon.service 是一個潛在的安全風險。它是 AccountsService 的一部分，AccountsService 允許程序獲得或操作用戶賬戶信息。我不認為有好的理由能使我允許這樣的后臺操作，所以我選擇掩蓋mask該服務進程。
- avahi-daemon.service 用于零配置網絡發現，使電腦超容易發現網絡中打印機或其他的主機，我總是禁用它，別漏掉它。
- 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
這個特定的例子沒有出現任何異常，但是如果存在系統啟動瓶頸，則該命令將能發現它。
你也能通過如下資源了解 Systemd 如何工作：
