| Generally, general-purpose Linux distributions launch various related service processes when booting, including many that you may not need What are the services used, such as Bluetooth, Avahi, modem manager, ppp-dns (LCTT translation annotation: the author's typo here ppp-dns should be pppd-dns) and other service processes? Where is it used and what is its function? |
Systemd provides many great tools for viewing system startup and controlling what is run at system startup. In this post, I'll explain how to shut down some nasty processes in a Systemd-like distribution.
View startup items
In the past, you could easily tell which service processes were started at boot by looking at /etc/init.d. Systemd is displayed in different ways. You can use the following command to list the service processes that are allowed to be started at boot.
$ 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 for me because I don't need Bluetooth functionality on this computer, so I don't need it running. The following command will stop the service process and prevent it from starting at boot.
$ sudo systemctl stop bluetooth.service $ sudo systemctl disable bluetooth.service
You can use the following command to determine whether the operation is successful.
$ 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 prevent the process from starting at system startup under any circumstances, there is no need to uninstall it, just 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 that disabling the process starts without adverse effects, you can also choose to uninstall the program.
By executing the command, you can get the following service list:
$ 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 are not meant to run on their own.
What services can be banned?
How do you know which services you need and which ones can be safely disabled? It always depends on your individual needs.
Here are some examples of the role of several service processes. Many service processes are distribution-specific, so you should look at your distribution's documentation (e.g. via Google or StackOverflow).
- accounts-daemon.service is a potential security risk. It is part of AccountsService, which 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 choose to mask the service process.
- avahi-daemon.service is used for zero-configuration network discovery, making it super easy for computers to discover printers or other hosts on the network. I always disable it so as not to miss it.
- brltty.service provides support for Braille devices, such as Braille displays.
- debug-shell.service opens a huge security hole (the service provides a passwordless root shell to help debugging systemd issues), never start a service unless you are using it.
- ModemManager.service This service is a daemon process activated by dbus to provide a mobile broadband (2G/3G/4G) interface. If you do not have this interface, whether it is a built-in interface or a phone paired via Bluetooth, and a USB adapter , then you don’t need this service.
- pppd-dns.service is a relic of computer development, keep it if you use dial-up for Internet access, otherwise you won't need it.
- rtkit-daemon.service sounds scary, it sounds like a rootkit. But you need this service because it is a real-time kernel scheduler.
- whoopsie.service is the Ubuntu error reporting service. It is used to collect Ubuntu system crash reports and send the reports to https://daisy.ubuntu.com. You can safely disable it from starting, or uninstall it permanently.
- wpa_supplicant.service is only required if you are using a Wi-Fi connection.
What happens when the system starts?
Systemd provides some commands to help debug system startup problems. This command will replay all the messages your system started.
$ 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. [...]
The command journalctl -b -1 can be used to review the previous startup, journalctl -b -2 can be used to review the second to last startup, and so on.
This command will print out a lot of information. You may not pay attention to all the information, but only to the part related to the problem. To this end, the system provides several filters to help you target. Let's take the example of process number 1, which is the parent process 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 has been started, or is being attempted to be started.
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
This particular example did not throw up any exceptions, but if there is a system startup bottleneck, this command will detect it.
You can also learn how Systemd works through the following resources:
Understanding and using Systemd
Introducing Systemd run level and service management commands
Moving forward again, another Linux initialization system: Introduction to Systemd
via: https://www.linux.com/learn/cleaning-your-linux-startup-process