LinuxCup CoffeeIssue #48 ·

Sample issue — written to show the newsletter format. This is not real news, and the repair story is a hypothetical scenario.

Always upgrading to the newest version doesn’t always make your system better

By the barista · About a 6-minute read · One hot latte

Hi everyone. I’m writing this issue just as the rain has stopped, and the coffee in my cup is still warm. There’s been a lot to think about this past week, especially a question I hear all the time from small business owners: “Should we always upgrade to the latest version?” So this issue tackles that head-on, walks through one repair job, and wraps up with some light kernel talk.

🔥 This Cup: LTS is a sysadmin’s best friend

I believe that production machines — a mail server, a file server, or the box that runs a dormitory’s Wi‑Fi — should run a long-term support (LTS) release of their distro in almost every case. The reason is simple: systems like these exist to “sit quietly and do their job”, not to be a playground for new things.

New releases do have real benefits: better features and better support for new hardware. But every change is a risk we pay for — in time spent testing, time spent fixing config files whose format changed, and time spent explaining to users why things look different. LTS releases still get regular security patches, so we stay secure without absorbing a major change every six months.

The best system is the one you don’t have to think about for a whole month.

But don’t mistake LTS for “no updates needed”. The difference is in the size of the update. Security patches should go in regularly — you can even install them automatically. Major version upgrades, on the other hand, should be planned, tested on a spare machine first, and done on a day when you have time to deal with problems. Not on a Friday afternoon.

On your own desktop or test machines, go ahead and run the newest releases — it’s fun. Just keep a clear line between which machines are “toys” and which ones your customers depend on.

🔧 What I Fixed This Week: A full disk because logs weren’t rotated

A hypothetical case that comes up all the time: one morning a user reports they can’t send email. You log in to the server and find the main partition at 100%. Services can’t write files, so they stop working one by one.

Step one is finding out what’s eating the space. These are the commands I use all the time:

df -h
sudo du -xh /var --max-depth=2 | sort -h | tail -n 15
journalctl --disk-usage

The culprit turned out to be one application’s log file, tens of gigabytes in size, because the app writes to its own file and no logrotate had been set up for it. The quick fix is to truncate the file to zero (not delete it — if a process still has the file open, the space won’t be freed).

sudo truncate -s 0 /var/log/myapp/app.log

Then fix the root cause by adding a logrotate config and capping the size of the systemd journal:

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
    copytruncate
}

# /etc/systemd/journald.conf
SystemMaxUse=1G

The lesson from this job: always set up an alert for when disk usage goes above 80%. Knowing a week ahead is much better than finding out when a customer calls at 7 a.m.

☕ Coffee & Kernel: Which kernel should you choose?

The Linux kernel comes in several branches. The ones most people should know are mainline, released periodically with the newest changes; stable, which carries bug fixes on top of mainline; and longterm, which is maintained for several years. Most distros already pick a kernel for you and add their own patches on top.

The simple advice: if the machine is already working well, use the kernel your distro ships. It has been tested together with the rest of the packages on the system. Only switch to a newer kernel when you have a clear reason, such as new hardware that isn’t supported yet. You can check which version you’re running with uname -r.

And don’t forget: after a kernel update, you need to reboot before the patch actually takes effect. I’ve seen plenty of machines with every patch installed that hadn’t been rebooted in a year.

📅 Community calendar (sample)

Before the cup runs dry

If there’s something you’d like covered in the next issue, or you want to argue with the “This Cup” column, just reply to this email. I read every one. See you in two weeks — take good care of your systems, and don’t forget to take a coffee break now and then.

— The barista, linuxcup.com