Just booted up, but your system's still feeling slow and sluggish? Linux runs many applications "in the background" that you might not even be aware of. Here's how to take control of them.
Linux Start-Up
We all know the drill: you hit the power button on your computer, wait for a bit, then come back to a nice-looking log-in. But what happens during that time? Old-school Linux users will remember the pages (and pages, and PAGES) of diagnostic messages that would scroll by. These messages contained info on drivers being loaded, file systems found, and different processes being started.
Let's take a quick look at what transpires between "power-on" and "desktop log-in."
- When you turn your computer on, the BIOS loads. This is software provided by the hardware manufacturer (separate from the operating system) and contains settings on the device from which you want to boot your session.
- The BIOS, depending on those settings, passes control to one of the computer's physical disks, specifically to its bootloader. While the bootloader can be set up to include configuration data, its primary job is to pass control on to an operating system. It provides an interface to select from among OSes if your computer has more than one. GRUB is the standard bootloader for most modern Linux distributions.
- When a bootloader starts up a Linux operating system, the kernel (or the heart of the operating system) is loaded. This will link up to your hardware, and then it starts a single process we'll call a start-up process.
- This start-up process is in turn responsible for starting all the other processes in the system. This includes server applications (including the X Server process on which your pretty desktop log-in will appear), so-called "daemons" (programs that wait in the background for specific events, such as the CUPS printing daemon), and others (like the cron daemon that executes programs on a schedule).
It is this last step that concerns us. By setting adjusting configurations you can control precisely what gets started by default.
Daemons vs. Services
In this article, we'll be using these terms interchangeably. There are technical differences between the two that are beyond the scope of this post. But for our purpose here they are the same, in that they can be controlled by the tools we'll review.
Why Fiddle With These Settings?
Why should you bother with any of this at all? Isn't it better to just leave the defaults?
Knowing how to configure what starts when your computer boots can provide a couple of benefits:
- Firstly, it can improve performance. Remember the time you installed Apache to try out that new web app? No? Well guess what, unless you uninstalled it that web server is running in the background, taking up precious RAM. Adjusting start-up settings means you can leave it installed, but just start it up when you need it. (Check out some other performance-enhancing tips here.)
- In addition, some of these programs may raise security issues. For example, the aforementioned Apache will be open to contact with port 80 while it's running. Should there be a security issue with Apache, having that port open to the world could put your system at risk. Better to start up the server when you need it and shut it down as soon as you're done.
Current Start-Up Processes
Today's Linux systems use a few main start-up systems, described below.
init
Long the standard start-up system, init traces its history back to the original Unix systems on which Linux was based (its proper name is SysVInit, drawing from System V Unix). The init system is based on a collection of start-up scripts, kept in the /etc/init.d or /etc/rc.d directories, and the concept of "runlevels." For example, desktop-oriented distributions will start you in "runlevel 5," which is defined as "multi-user mode with networking + X display manager." This is why when you start up one of these distributions, you'll immediately end up with an X-system-based graphical desktop log-in.
The init system adheres to the Unix philosophy, in that it does one thing and does it well. One of the arguments voiced by proponents of the system is that it doesn't try to do too much, unlike some of the following alternatives.
Upstart
The Upstart system was Canonical's attempt to replace the aging init system. It provides compatibility with the init system, but also provides additional features. Support for "events" allow it to react to changes in the system, such as plugging in new hardware. In addition, Upstart can work alongside the older init configurations, providing backwards support for older packages and software.
However once Debian (the upstream source for Ubuntu packages) made the switch to systemd, Canonical decided to do the same. The release of Ubuntu 15.04 (Vivid Vervet) was the first to feature the new start-up system by default.
systemd
It instigated one of the great flame wars of our time. In light of the perceived shortcomings of init (which are highlighted here), systemd (or the system daemon) was developed. This uses a completely new system with the goal of starting a service "when all its conditions are met." Like Upstart however, it can still support the init-style scripts provided by many packages, with a few notable exceptions.
Note in the image above how directories have names like "this.thing.wants." This demonstrates systemd's "on-demand" behavior -- when something "wants" bluetooth access and the conditions are met, systemd will start the service for it.
Tools to Manage Daemons/Services
While it never hurts to learn how to do so from the command line (check out the service command for init/Upstart, and sysctl for systemd), below are some helper applications for administering your services. While you may have the need to tweak their configuration, by and large you'll want to either enable them, or set them to run automatically by default, or disable them. Note that disabled services can still be started (and subsequently stopped) whenever you like.
init.d
For many users, the rcconf tool (in combination with the aforementioned service) will do everything you need. A text user interface (TUI) lists all the available services. You can use the arrow keys to move up and down the list, and the space bar to toggle whether the service should start (with an asterisk) or not. Use the Tab key to move between the list and the OK/Cancel buttons and space bar also to select them.
Install it in Ubuntu with the following:
sudo apt-get install rcconf
Red Hat developed the Service Configuration Tool, a graphical app which also appears by default in its derivatives such as CentOS and Fedora. It provides a similar list to rcconf above, and gives a similar list with the ability to check and uncheck services in order to set them to run by default or not. It also provides buttons that allow you start/stop/restart those services.
systemd
The KDE developers created a module for their System Settings application to control systemd services. Located under the System Administration category, it allows you to view the state of, enable/disable, and edit the configuration of services (or "units"). It also contains an editor for the systemd configuration files.
Install it in Ubuntu with the following:
sudo apt-get install kde-config-systemd
systemd-manager is a GTK-based app available in some repositories (including Fedora and Arch), while Ubuntu users can grab a .DEB file from it's GitHub page [No Longer Available]. The UI is a little different, as it's written in Rust, but it's easy enough to find the controls to enable/disable and start/stop the services, while the large center pane allows you to edit the configuration.
Once you've downloaded the package you can install it with:
sudo dpkg -i systemd-manager-download.deb
Also for GTK-based desktops, the systemadm tool provides you a way to start/stop/restart services. Install it in Ubuntu with the following:
sudo apt-get install systemd-ui
The Future Is systemd
While we've equally highlighted two main start-up management systems in this article, init and systemd, most mainstream distributions are moving towards the latter. Even Canonical, who'd created their own alternative, saw the writing on the wall and included systemd by default.
Do you have a preference or are these just invisible background processes to you? Have any tips or tricks to managing these things? Let us know in the comments!