Cleaning Up Your Linux Startup Process

By

-

May 18, 2016

The average general-purpose Linux distribution launches all kinds of stuff at startup, including a lot of services that don’t need to be running. Bluetooth, Avahi, ModemManager, ppp-dns… What are these things, and who needs them?

Systemd provides a lot of good tools for seeing what happens during your system startup, and controlling what starts at boot. In this article, I’ll show how to turn off startup cruft on Systemd distributions.

View Boot Services

In the olden days, you could easily see which services were set to launch at boot by looking in /etc/init.d. Systemd does things differently. You can use the following incantation to list enabled boot services:

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

And, there near the top is my personal nemesis: Bluetooth. I don’t use it on my PC, and I don’t need it running. The following commands stop it and then disable it from starting at boot:

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

You can confirm by checking the status:

$ 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 disabled service can be started by another service. If you really want it dead, without uninstalling it, then you can mask it to prevent it 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 a service has no bad side effects, you may elect to uninstall it.

You can generate a list of all services:

$ 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 these are dependencies of other systemd services and are not meant to run by themselves.

Can I Get Rid of These Services?

How do you know what you need, and what you can safely disable? As always, that depends on your particular setup.

Here is a sampling of services and what they are for. Many services are distro-specific, so have your distribution documentation handy (i.e., Google and Stack Overflow).

accounts-daemon.service is a potential security risk. It is part of AccountsService, which allows programs to get and manipulate user account information. I can’t think of a good reason to allow this kind of behind-my-back operations, so I mask it.

avahi-daemon.service is supposed to provide zero-configuration network discovery, and make it super-easy to find printers and other hosts on your network. I always disable it and don’t miss it.
brltty.service provides Braille device support, for example, Braille displays.
debug-shell.service opens a giant security hole and should never be enabled except when you are using it. This provides a password-less root shell to help with debugging systemd problems.
ModemManager.service is a DBus-activated daemon that controls mobile broadband (2G/3G/4G) interfaces. If you don’t have a mobile broadband interface — built-in, paired with a mobile phone via Bluetooth, or USB dongle — you don’t need this.

pppd-dns.service is a relic of the dim past. If you use dial-up Internet, keep it. Otherwise, you don’t need it.
rtkit-daemon.service sounds scary, like rootkit, but you need it because it is the real-time kernel scheduler.
whoopsie.service is the Ubuntu error reporting service. It collects crash reports and sends them to https://daisy.ubuntu.com. You may safely disable it, or you can remove it permanently by uninstalling apport.
wpa_supplicant.service is necessary only if you use a Wi-Fi network interface.

What Happens During Bootup

Systemd has some commands to help debug boot issues. This command replays all of your boot messages:

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

You can review previous boots with journalctl -b -1, which displays the previous startup; journalctl -b -2 shows two boots ago, and so on.

This spits out a giant amount of output, which is interesting but maybe not all that useful. It has several filters to help you find what you want. Let’s look at PID 1, which is the parent process for 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.
[...]

This shows what was started — or attempted to start.

One of the most useful tools is systemd-analyze blame, which shows which services are taking the longest to start up.

$ 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 doesn’t show anything unusual, but if there is startup bottleneck, this command will find it.

You may also find these previous Systemd how-tos useful:

The Democratization of Containerization

By

Amber Ankerholz

-

May 18, 2016

https://www.youtube.com/watch?v=DpITUaDSUck?list=PLGeM09tlguZQ17kXq679jthIhf12Tkat9

Docker catalyzed the software industry, causing it to reach a new level of innovation and growth. Docker’s success, however, was unforeseen, said Scott Johnston in his keynote talk at Collaboration Summit. Looking back, the key elements were: Accessibility, Portability, and Openness.

3 Reasons Docker and Containerization Lit Up Application Development [Video]

By

Daniel P. Dern

-

May 18, 2016

Docker was the flame that catalyzed innovation in application development, according to Scott Johnston, senior vice president of product management and design at Docker. However, that success was entirely unforeseen.

“I wish I could say that we had a premeditated mindset three years ago when we released Docker,” Johnston said in his keynote at last month’s Collaboration Summit. “But we did not.” Looking back, he sees three main reasons for Docker’s success: Accessibility, Portability, and Openness.

Docker has become one of the major players in container management and deployment, and, in his keynote — called “The Democratization of Containerization” — Johnston shared some of the thoughts that led to the creation of Docker, its success, and what has to happen next.

“Software is eating the world,” said Johnston, referencing a recurring theme at the summit and describing how software has disrupted long-established businesses and industries, starting with books, travel, and real estate, followed by media, hospitality, and even cars. “You have to be concerned about how software will disrupt your business,” he said.

And, according to Johnston, although interpretive languages like Ruby and Python, methodologies like Agile, Lean, and Kanban, and collaborative technologies and methods have made software development easier, the work doesn’t stop when you commit and check in the app. “You have to transcend the application pipeline beyond development, beyond QA, into staging, into operations, and into ongoing maintenance.” He went on to say that until the team works across the entire lifecycle, you don’t see the full potential of applications.

Industry Growth and What’s Next

Then, three years ago, Johnston recalled, Docker entered the conversation. He reflected on why Docker was the flame that catalyzed this industry and caused it to take off to a new level of innovation and growth. The reasons boil down to accessibility, portability, and openness, Johnston explained.

Accessible: By making the tools available at the command line, “You can get very powerful isolation and resource management, without having to know anything about kernels.”
Portable: “That image inside a Docker container, its only dependency is a Linux kernel. So it can go from developer’s laptop running Linux to a server in the data center running Linux on OpenStack, to a server in Amazon cloud running Linux, all without change.” Among other benefits, said Johnson, “It started an ecosystem where ISVs felt confident putting their software into the Docker containers and into the Docker image format, because they knew they didn’t have to go back and redo a build for Red Hat, for Ubuntu, for Debian.”
Open: Openness, Johnston said, “made it possible for developers and sys admins to download and start to use Docker, and it allows for massive community contributions.” Also, he pointed out, Docker includes an API for plug-ins — for different stacks for file systems, networking, storage, etc.

What’s next, said Johnston, is taking each of these features to the next level.

For Accessible 2.0, “We have to continue to make it accessible for those not in this [keynote] room… reference architectures and reference stacks are exactly what we need to do to get that next wave of the market adopting our solution,” Johnston said.

One particularly exciting development, he noted, is the enabling of Windows to use containers and microservices. Johnston said that recently a customer with 10,000 Visual Studio developers asked him point blank whether he should retrain them all on Java and Linux. Johnston answered, “No, if you want to take advantage of microservices, this new cloud native computing model, it’s coming with Microsoft.”

Portable 2.0, according to Johnston, reflects the fact that “a single container does not a full application make. Applications are combinations of containers, and applications need networking and storage and security.”

Finally, comes Open 2.0, which involves continuing activities like evolving de facto standards and building reference stacks, Johnston said, citing the work of the Open Container Initiative (OCI) and Cloud Native Computing Foundation.

The steps must be accomplished, Johnston concluded, “so that we, our users, our customers, and this entire industry can get the benefits of this decade-long disruption.”

Watch Scott Johnston’s full keynote, below.

https://www.youtube.com/watch?v=DpITUaDSUck?list=PLGeM09tlguZQ17kXq679jthIhf12Tkat9

DevOps Model, A Profile in CIO Leadership, Change Management

By

Tech Target

-

May 18, 2016

Take it from IT leaders who have been there: Adopting a DevOps model will require strong leadership, exceptional people skills, a high tolerance for failure and financial savvy.

CTO Alexander Pluim described his company’s situation as typical: An enterprise technology system has issues, no one is sure what is going wrong, but each worker is positive it isn’t his fault. Fortunately for Pluim, CTO at Amsterdam-based BVA Auctions, he realized the reason for his team’s predicament.

“When I looked at people behind their desks, trying to guess on their own without communicating with the other disciplines, I was amazed,” he said. The different disciplines — developers, DBAs, IT operations folks — had no insight into what the others were doing.

F5’s Latest Updates Give a Nod to Developers

By

SDx Central

-

May 18, 2016

As virtual appliances become a bigger part of its business, F5 is tweaking some of its products to better fit the concept of developers programming the network.

The company has separated its orchestration tool from its management tool. The latter, which involves monitoring the network and making sure features such as high availability are viable, is still within the purview of networking people. But orchestration and provisioning of services is becoming more of a programmer’s job. “It turns out they’re used by different people,” says Lori MacVittie, F5’s principal technical evangelist. “The folks who are, day-to-day, managing devices and managing certificates, just checking the health of the devices in the network, are not the same people who are doing orchestration.”

Building and Scaling the Fastly Network, Part 1: Fighting the FIB

By

Fastly Blog

-

May 18, 2016

This post is the first in a series detailing the evolution of network software at Fastly. We’re unique amongst our peers in that from inception, we’ve always viewed networking as an integral part of our product rather than a cost center. We rarely share what we do with the wider networking community however, in part because we borrow far more from classic systems theory than contemporary networking practice.

Building abstractions

Before delving further, it is important to disambiguate that while we write software for networks, we shy away from using the term software-defined networking (SDN) to describe what we do.

Fifty Shades of Open

By

First Monday

-

May 18, 2016

Open source. Open access. Open society. Open knowledge. Open government. Even open food. Until quite recently, the word “open” had a fairly constant meaning. The over-use of the word “open” has led to its meaning becoming increasingly ambiguous. This presents a critical problem for this important word, as ambiguity leads to misinterpretation.

“Open” has been applied to a wide variety of words to create new terms, some of which make sense, and some not so much. When we started writing this essay, we thought our working title was simply amusing. But the working title became the actual title, as we found that there are at least 50 different terms in which the word “open” is used, encompassing nearly as many different criteria for openness. In this essay we will attempt to make sense of this open season on the word “open.”

Univa Manages Enterprise Container Workloads on Kubernetes Distros

By

insideHPC

-

May 18, 2016

Today Univa announced Navops Command, a ground breaking software suite that implements sophisticated workload placement and advanced policy management for enterprises to take full advantage of containers on any Kubernetes distribution.

In addition, Navops provides the unique ability to better maximize utilization of shared resources and manage service applications running at scale. Navops Command’s ability to run on any Kubernetes distribution means that customers can choose to work with any number of vendors participating in the CNCF (Cloud Native Computing Foundation), like RedHat’s OpenShift, Navops Launch or CoreOS’s Tectonic, and still get the benefit of Command’s advanced policy management.

Symantec Antivirus Security Flaw Exposes Linux, Mac, and Windows

By

Engadget

-

May 18, 2016

Security holes in antivirus software are nothing new, but holes that exist across multiple platforms? That’s rare… but it just happened. Google’s Tavis Ormandy has discovered a vulnerability in Symantec’s antivirus engine (used in both Symantec- and Norton-branded suites) that compromises Linux, Mac and Windows computers. If you use an early version of a compression tool to squeeze executables, you can trigger a memory buffer overflow that gives you root-level control over a system.

The kickers are that it’s both easy to launch the exploit and particularly vicious in most cases. As Symantec is intercepting system input and output, you only need to email a file — the victim doesn’t even need to read the email, just the act of AV scanning it is a trigger — or send a web link to wreck someone’s day.

Patch Now: Google and JetBrains Warn Developers of Buggy IDE

By

The Register

-

May 18, 2016

Google has emailed Android developers advising them to update Android Studio, the official Android IDE, to fix security bugs. Other versions of the JetBrains IntelliJ IDE, on which Android Studio is based, are also affected.

The bugs are related to the built-in web server in the IDE. A cross-site request forgery (CSRF) flaw means that if the IDE is running and the developer visits a malicious web page in any browser, scripts on the malicious web page could access the local file system.