Shulou(Shulou.com)06/01 Report--

The main content of this article is "how to clean up the startup items of the Linux system", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to clean up the startup items of the Linux system.

View boot startup items

In the past, you could easily tell which service processes would start at boot time by looking at / etc/init.d. Systemd is presented in different ways, and you can use the following command to list the service processes that are allowed to boot up.

$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 [..]

At the top of this list, the Bluetooth service is redundant to me because I don't need to use Bluetooth on this computer, so I don't need to run this service. The following command stops the service process and keeps it from booting up.

$sudo systemctl stop bluetooth.service $sudo systemctl disable bluetooth.service

You can determine whether the operation is successful by using the following command.

$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)

A deactivated service process can still be started by another service process. If you really want to not start the process when the system starts under any circumstances, you don't need to uninstall it, you just need to cover it up to prevent the process from starting under any circumstances.

$sudo systemctl mask bluetooth.service Created symlink from / etc/systemd/system/bluetooth.service to / dev/null.

Once you are satisfied with disabling the process without negative effects, you can also choose to uninstall the program.

The following list of services can be obtained by executing the command:

$systemctl list-unit-files-type=service UNIT FILE STATE accounts-daemon.service enabled acpid.service disabled alsa-restore.service static alsa-utils.service masked

You cannot enable or disable static services because static services are dependent on other processes and do not mean they run on their own.

Which services can be banned?

How do you know which services you need and which can be safely disabled? It always depends on your personalized needs.

Here are examples of the role of several service processes. Many service processes are release-specific, so you should look at your distribution documentation (for example, through google or StackOverflow).

Accounts-daemon.service is a potential security risk. It is part of AccountsService, and AccountsService allows programs to obtain or manipulate user account information. I don't think there is a good reason for me to allow such background operations, so I chose to mask the mask service process.

Avahi-daemon.service is used for zero configuration network discovery, making it super easy for computers to find printers or other hosts in the network. I always disable it. Don't miss it.

Brltty.service provides support for Braille devices, such as Braille displays.

Debug-shell.service opens up a huge security vulnerability (the service provides a password-less root shell to help debug systemd problems), and never start the service unless you are using it.

ModemManager.service this service is a daemon activated by dbus to provide a mobile broadband broadband (2G/3G/4G) interface, and if you do not have this interface, whether it is a built-in interface, or through a paired phone such as Bluetooth, and a USB adapter, then you do not need this service.

Pppd-dns.service is a relic of computer development, if you use dial-up access to the Internet, keep it, otherwise you don't need it.

Rtkit-daemon.service sounds terrible. It sounds like rootkit. But you need this service because it is a real-time kernel scheduler real-time kernel scheduler.

Whoopsie.service is the Ubuntu error reporting service. It is used to collect Ubuntu system crash reports and send reports to https://daisy.ubuntu.com. You can safely disable it from starting, or uninstall it.

Wpa_supplicant.service is only needed if you are using Wi-Fi to connect.

What happens when the system starts up?

Systemd provides some commands to help debug system boot problems. This command will replay all messages that your system starts.

$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: 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. [...]

By ordering journalctl-b-1, you can review the previous startup, journalctl-b-2 can review the penultimate startup, and so on.

This command will print out a lot of information, and you may not pay attention to all the information, but only to the relevant parts of the problem. To this end, the system provides several filters to help you lock in the target. Let's take the process with process number 1 as an example, which is the parent of all other processes.

$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. [...]

These print messages show what is started or is trying to start.

One of the most useful command tools, systemd-analyze blame, is used to help see which service process takes the longest to start.

$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

There is no exception in this particular example, but if there is a system startup bottleneck, the command will find it.

At this point, I believe you have a deeper understanding of "how to clean up the startup items of the Linux system". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.