Linux Café

Introduction to Resource Management

I’ve seen this go wrong when a resource-intensive job is running in the background - it can consume significant CPU, memory, or I/O resources, slowing down other system activities. To mitigate this, Linux provides two essential tools: nice and ionice. In this article, we’ll explore how to use these tools to tame resource-intensive background jobs and maintain a smooth system experience.

Understanding nice

The nice command is used to adjust the scheduling priority of a process. By default, Linux assigns a nice value of 0 to each process, which means it has a normal scheduling priority. You can adjust this value using the nice command, with values ranging from -20 (highest priority) to 19 (lowest priority). For example:

Introduction to Journalctl Filtering

I’ve seen this go wrong when you’re trying to troubleshoot an issue and journalctl spits out a wall of text. By default, it displays all available log messages, which can be overwhelming, especially on systems with many services running. The output includes the timestamp, hostname, syslog identifier, and the actual log message. To make sense of this output, you can use various options and filters provided by journalctl.

Introduction to systemd-resolved

I’ve always been curious about how my Linux system resolves domain names. Recently, I’ve been dealing with some DNS resolution issues at home, which led me to dig into systemd-resolved. As it turns out, many Linux distributions, including Ubuntu and Fedora, use systemd-resolved as their DNS resolver by default. In this article, I’ll share my experience with getting reliable DNS resolution at home using systemd-resolved.

Understanding systemd-resolved

systemd-resolved is part of the systemd suite and provides a DNS resolver service. It’s designed to be a caching, validating, and recursive DNS resolver - which means it can cache DNS responses, validate DNSSEC records, and perform recursive DNS lookups. To check if systemd-resolved is running on your system, you can use the following command:

Introduction to Self-Hosted Chaos

I’ve been self-hosting various services at home for a while now, and one thing that’s always been a pain point is managing SSL certificates. With multiple services running on different machines, each requiring its own certificate, it’s easy to lose track of which ones are due for renewal. I’ve seen this go wrong when a certificate expires unexpectedly, taking down a service with it. To avoid this, I’ve implemented a centralized certificate management system, which I’ll outline in this article.

Taming Terminal History Chaos

I’ve spent years working in the terminal, and my command history has grown out of control. It’s frustrating when you need to recall a specific command, but it’s buried deep in your history. I’ve seen this go wrong when trying to debug an issue or repeat a complex process. Recently, I decided to take matters into my own hands and create a custom Bash setup to organize my command line history.

Introduction to Log Noise

I’ve learned the hard way that managing log files is crucial to keeping my small home server running smoothly. Log noise, in particular, can be a real pain - it’s like trying to find a needle in a haystack. In this article, I’ll share how I use journalctl and logrotate to tame log noise and keep my system healthy.

Understanding Log Noise

Log noise refers to the overwhelming amount of log data generated by various system components. This noise makes it tough to spot critical errors or security issues. In a small home server setup, log noise can lead to disk space issues, slow down performance, and make troubleshooting a nightmare. I’ve seen this go wrong when I neglected to monitor my log files, and it wasn’t pretty.

Introduction to Taming Removable Device Chaos

I’ve lost count of how many times I’ve struggled with removable devices on Linux. Whether it’s a USB drive, an SD card, or an external hard drive, these devices can be a real hassle. But over the years, I’ve learned a thing or two about how to keep them in check using Udev rules and automount tweaks.

Understanding Udev

Udev is the device manager for Linux, and it’s what creates device nodes in the /dev directory and handles device hotplugging. The real trick is using Udev rules to customize its behavior. To get started, you’ll need to create a new file in the /etc/udev/rules.d directory. I usually start with a file like 99-removable-devices.rules, which you can create using the following command:

Introduction to Log Noise

I’ve seen this go wrong when you’re drowning in a sea of log data - it’s overwhelming, to say the least. With systemd’s journaling capabilities, logging has become more efficient and centralized, but that also means you’re dealing with a massive volume of log data. This is where people usually get burned, as it’s tough to identify real issues. That’s where journalctl comes in - a powerful command-line utility for querying and managing systemd journals.

Introduction to Rescuing Borked Linux Systems

I’ve seen this go wrong when you least expect it - a misconfigured system file, a failed update, or an accidental deletion of a critical file can leave your Linux system in a borked state. Whether you’re working on a desktop, server, or in a homelab setup, having a reliable method to rescue and restore your system is invaluable. In my experience, rsync combined with temporary snapshots is one of the most effective tools for this purpose.

Introduction to systemd Recovery

I’ve seen this go wrong when a systemd update fails - it’s a pretty stressful experience, especially when systemd is the core init system for your Linux distribution. Recently, I had a similar issue on my small home server. The update process seemed fine at first, but after a reboot, I was greeted with an error message indicating that systemd had failed to start.

Identifying the Problem

The real trick is to stay calm and use the right tools to diagnose the issue. I booted into rescue mode using a live USB stick, which gave me access to the filesystem. From there, I inspected the systemd logs using the following command: