PRF:20160518 Cleaning Up Your Linux Startup Process.md

@penghuster 请对照我的校对。
This commit is contained in:
wxy 2017-09-03 16:38:40 +08:00
parent 65e73cfbf7
commit 590ed2edc5

View File

@ -1,13 +1,16 @@
Linux 系统开机启动项清理 Linux 系统开机启动项清理
======= =======
![Linux cleanup](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/banner-cleanup-startup.png?itok=dCcKwdoP "Clean up your startup process") ![Linux cleanup](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/banner-cleanup-startup.png?itok=dCcKwdoP "Clean up your startup process")
一般情况下, Linux 发行版在开机启动时拉起所有的相关服务进程, 包括许多你可能无需使用的服务, 例如<ruby>蓝牙<rt>bluetooth</rt></ruby>, Avahi, <ruby>调制解调管理器<rt>ModemManager</rt></ruby>, ppp-dns(LCTT 译注:此处作者笔误 ppp-dns 应该为 pppd-dns) 等服务进程, 用于哪里, 有何功能? 一般情况下,常规用途的 Linux 发行版在开机启动时拉起各种相关服务进程,包括许多你可能无需使用的服务,例如<ruby>蓝牙<rt>bluetooth</rt></ruby>、Avahi、 <ruby>调制解调管理器<rt>ModemManager</rt></ruby>、ppp-dnsLCTT 译注:此处作者笔误 ppp-dns 应该为 pppd-dns) 等服务进程,这些都是什么东西?用于哪里,有何功能?
systemd 提供了许多很好的工具, 用于查看系统启动情况, 控制系统启动工作. 该文章中将说明在 systemd 控制系统启动的过程中如何关闭一些<ruby>令人讨厌<rt>cruft</rt></ruby>的进程。 Systemd 提供了许多很好的工具用于查看系统启动情况,也可以控制在系统启动时运行什么。在这篇文章中,我将说明在 Systemd 类发行版中如何关闭一些令人讨厌的进程。
###查看开机启动项 ### 查看开机启动项
在老式系统启动方式 systemV 中,在 /etc/init.d 中你能很容易看到服务进程是否被设置为开机启动项。Systemd 以不同的方式展现,可以使用如下命令罗列允许开机启动的服务进程。
在过去,你能很容易通过查看 `/etc/init.d` 了解到哪些服务进程会在引导时启动。Systemd 以不同的方式展现,你可以使用如下命令罗列允许开机启动的服务进程。
``` ```
$ systemctl list-unit-files --type=service | grep enabled $ systemctl list-unit-files --type=service | grep enabled
accounts-daemon.service enabled accounts-daemon.service enabled
@ -16,13 +19,17 @@ anacron.service enabled
bluetooth.service enabled bluetooth.service enabled
brltty.service enabled brltty.service enabled
[...] [...]
``` ```
在此列表中, 对我来说, 蓝牙服务是冗余项, 因为在该电脑上我不需要使用蓝牙功能, 故无需运行此服务. 下面的命令将停止该服务进程,并且使其开机不启动。
在此列表顶部,对我来说,蓝牙服务是冗余项,因为在该电脑上我不需要使用蓝牙功能,故无需运行此服务。下面的命令将停止该服务进程,并且使其开机不启动。
``` ```
$ sudo systemctl stop bluetooth.service $ sudo systemctl stop bluetooth.service
$ sudo systemctl disable bluetooth.service $ sudo systemctl disable bluetooth.service
``` ```
你可以通过下面命令确定是否操作成功。 你可以通过下面命令确定是否操作成功。
``` ```
$ systemctl status bluetooth.service $ systemctl status bluetooth.service
bluetooth.service - Bluetooth service bluetooth.service - Bluetooth service
@ -30,14 +37,18 @@ $ systemctl status bluetooth.service
Active: inactive (dead) Active: inactive (dead)
Docs: man:bluetoothd(8) Docs: man:bluetoothd(8)
``` ```
一个开机不启动的服务进程仍然能够被另外一个服务进程启动。如果你真的想在任何情况下系统启动时都不启动该进程,你可以卸载该程序;若在不卸载程序的情况达到此效果,你可以执行如下命令在任何情况下阻止该进程开机启动。
停用的服务进程仍然能够被另外一个服务进程启动。如果你真的想在任何情况下系统启动时都不启动该进程,无需卸载该它,只需要把它掩盖起来就可以阻止该进程在任何情况下开机启动。
``` ```
$ sudo systemctl mask bluetooth.service $ sudo systemctl mask bluetooth.service
Created symlink from /etc/systemd/system/bluetooth.service to /dev/null. Created symlink from /etc/systemd/system/bluetooth.service to /dev/null.
``` ```
一旦你对禁止该进程启动的效果感到满意时,你也可以选择卸载该程序。
一旦你对禁用该进程启动而没有出现负面作用感到满意,你也可以选择卸载该程序。
通过执行命令可以获得如下服务列表: 通过执行命令可以获得如下服务列表:
``` ```
$ systemctl list-unit-files --type=service $ systemctl list-unit-files --type=service
UNIT FILE STATE UNIT FILE STATE
@ -46,26 +57,29 @@ acpid.service disabled
alsa-restore.service static alsa-restore.service static
alsa-utils.service masked alsa-utils.service masked
``` ```
你不能使能或使不能静态服务,因为静态服务是依赖于其他的进程,意味着其不能自启动。
你不能启用或禁用静态服务,因为静态服务被其他的进程所依赖,并不意味着它们自己运行。
###哪些服务能够禁止? ### 哪些服务能够禁止?
如何知道你是否能够禁止某服务或需要何服务?它总是依赖于你的个性化需求。 如何知道你需要哪些服务,而哪些又是可以安全地禁用的呢?它总是依赖于你的个性化需求。
这里有列出了几个服务进程的作用,所有服务进程都可以在发行版规范中找到,你也可以通过搜索方式查询起作用 这里举例了几个服务进程的作用。许多服务进程都是发行版特定的,所以你应该看看你的发行版文档(比如通过 google 或 StackOverflow
- accounts-daemon. 该服务存在潜在的安全威胁。它是账号服务的一部分,它被允许获得或操作用户账户信息。我不认为存在一个好的理由能使我允许这样的后台操作,所以我选择<ruby>掩盖<rt>mask</rt></ruby>该服务进程。 - **accounts-daemon.service** 是一个潜在的安全风险。它是 AccountsService 的一部分AccountsService 允许程序获得或操作用户账户信息。我不认为有好的理由能使我允许这样的后台操作,所以我选择<ruby>掩盖<rt>mask</rt></ruby>该服务进程。
- avahi-daemon. 该服务用于零配置网络发现,使电脑极易发现网络中打印机或其他的主机,我总是使其开机不启动,并从未不习惯于此 - **avahi-daemon.service** 用于零配置网络发现,使电脑超容易发现网络中打印机或其他的主机,我总是禁用它,别漏掉它
- brltty.service. 该服务提供布莱叶盲文设备支持,例如布莱叶盲文显示器。 - **brltty.service** 提供布莱叶盲文设备支持,例如布莱叶盲文显示器。
- debug-shell.service. 该服务打开一个重要的安全漏洞(该服务提供了一个无密码的 root 用户用于帮助 systemd 问题的调试。),除非你正在使用该服务,否则永远不要启动服务。 - **debug-shell.service** 开放了一个巨大的安全漏洞(该服务提供了一个无密码的 root shell ,用于帮助 调试 systemd 问题),除非你正在使用该服务,否则永远不要启动服务。
- ModemManager.service. 该服务是一个被 dbus 激活的守护进程,用于提供移动<ruby>宽频<rt>broadband</rt></ruby>2G/3G/4G接口如果你不需要该内置接口通过如蓝牙、USB 适配器等来连接手机,那么你也无需该服务。 - **ModemManager.service** 该服务是一个被 dbus 激活的守护进程,用于提供移动<ruby>宽频<rt>broadband</rt></ruby>2G/3G/4G接口如果你没有该接口,无论是内置接口,还是通过如蓝牙配对的电话,以及 USB 适配器,那么你也无需该服务。
- pppd-dns.service. 该是一个计算机发展的遗物,如果你需要通过互联网打电话的话,保留它,否则<ruby>掩盖<rt>mask</rt></ruby>它。 - **pppd-dns.service** 是一个计算机发展的遗物,如果你使用拨号接入互联网的话,保留它,否则你不需要它。
- rtkit-daemon.service. 该服务听起来很可怕, 其发音与 rootkit 相似. 但是你需要该服务, 因为它是一个<ruby>实时内核调度器<rt>real-time kernel scheduler</rt></ruby>. - **rtkit-daemon.service** 听起来很可怕,听起来像是 rootkit。 但是你需要该服务,因为它是一个<ruby>实时内核调度器<rt>real-time kernel scheduler</rt></ruby>
- whoopsie.service. 该服务是 Ubuntu 错误报告服务. 它用于收集 Ubuntu 系统崩溃报告,并发送报告到 https://daisy.ubuntu.com. 你可以放心地禁止其启动, 或者永久的卸载它. - **whoopsie.service** 是 Ubuntu 错误报告服务。它用于收集 Ubuntu 系统崩溃报告,并发送报告到 https://daisy.ubuntu.com 。 你可以放心地禁止其启动,或者永久的卸载它。
- wpa_supplicant.service. 该服务仅仅在 Wi-Fi 连接时需要. - **wpa_supplicant.service** 仅在你使用 Wi-Fi 连接时需要。
###系统<ruby>启动<rt>bootup</rt></ruby>时发生什么? ### 系统启动时发生了什么?
systemd 提供了一些命令帮助调试系统开机启动问题. 该命令重演系统启动的消息打印.
Systemd 提供了一些命令帮助调试系统开机启动问题。该命令会重演你的系统启动的所有消息。
``` ```
$ journalctl -b $ journalctl -b
@ -78,9 +92,11 @@ Leaving at least 235.9M free (of currently available 1.5G of space).
Enforced usage limit is thus 157.2M. Enforced usage limit is thus 157.2M.
[...] [...]
``` ```
通过命令 `journalctl -b -1` 可以复审前一次启动, `journalctl -b -2` 可以复审倒数第2次启动, 以此类推.
通过命令 `journalctl -b -1` 可以复审前一次启动,`journalctl -b -2` 可以复审倒数第 2 次启动,以此类推。
该命令会打印出大量的信息,你可能并不关注所有信息,只是关注其中问题相关部分。为此,系统提供了几个过滤器,用于帮助你锁定目标。让我们以进程号为 1 的进程为例,该进程是所有其它进程的父进程。
该命令打印出大量的信息. 你可能并不关注所有信息, 只是关注其中问题相关部分. 为此, 系统提供了几个过滤命令, 用于帮助你锁定目标. 让我们以进程号为 1 的进程为例, 该进程是所有其他进程的父进程.
``` ```
$ journalctl _PID=1 $ journalctl _PID=1
@ -92,9 +108,11 @@ 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. May 08 06:18:17 studio systemd[1]: Listening on CUPS Scheduler.
[...] [...]
``` ```
这些打印消息显示了什么被启动, 或者是正在尝试启动.
这些打印消息显示了什么被启动,或者是正在尝试启动。
一个最有用的命令工具之一 `systemd-analyze blame`, 用于帮助查看哪个服务进程启动耗时最长. 一个最有用的命令工具之一 `systemd-analyze blame`,用于帮助查看哪个服务进程启动耗时最长。
``` ```
$ systemd-analyze blame $ systemd-analyze blame
8.708s gpu-manager.service 8.708s gpu-manager.service
@ -107,17 +125,21 @@ $ systemd-analyze blame
1.800s lm-sensors.service 1.800s lm-sensors.service
1.800s grub-common.service 1.800s grub-common.service
``` ```
这是一个没有任何异常的特殊样例, 但是如果存在系统启动<ruby>瓶颈<rt>bottleneck</rt></ruby>, 则该命令将发现它.
这个特定的例子没有出现任何异常,但是如果存在系统启动瓶颈,则该命令将能发现它。
你也能了解 systemd 如何工作通过如下资源: 你也能通过如下资源了解 Systemd 如何工作:
- [Understanding and Using Systemd](https://www.linux.com/learn/understanding-and-using-systemd)
- [Intro to Systemd Runlevels and Service Management Commands](https://www.linux.com/learn/intro-systemd-runlevels-and-service-management-commands) - [理解和使用 Systemd](https://www.linux.com/learn/understanding-and-using-systemd)
- [Here We Go Again, Another Linux Init: Intro to systemd](https://www.linux.com/learn/here-we-go-again-another-linux-init-intro-systemd) - [介绍 Systemd 运行级别和服务管理命令](https://www.linux.com/learn/intro-systemd-runlevels-and-service-management-commands)
- [再次前行,另一个 Linux 初始化系统Systemd 介绍](https://www.linux.com/learn/here-we-go-again-another-linux-init-intro-systemd)
----
via: https://www.linux.com/learn/cleaning-your-linux-startup-process via: https://www.linux.com/learn/cleaning-your-linux-startup-process
作者:[David Both](https://www.linux.com/users/cschroder) 作者:[David Both](https://www.linux.com/users/cschroder)
译者:[penghuster](https://github.com/penghuster) 译者:[penghuster](https://github.com/penghuster)
校对:校对者ID 校对:[wxy](https://github.com/wxy)
本文由 LCTT 原创编译Linux中国 荣誉推出 本文由 LCTT 原创编译Linux中国 荣誉推出