<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Journald on Linux Café</title>
    <link>https://mrtomlinux.org/tags/journald/</link>
    <description>Recent content in Journald on Linux Café</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Fri, 25 Sep 2026 09:19:19 +0200</lastBuildDate>
    <atom:link href="https://mrtomlinux.org/tags/journald/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>When systemd‑journald ate my 2 GB SSD: how I capped it to 200 MB in a single config line</title>
      <link>https://mrtomlinux.org/post/2026-09-25-when-systemdjournald-ate-my-2gb-ssd-how-i-cap/</link>
      <pubDate>Fri, 25 Sep 2026 09:19:19 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-09-25-when-systemdjournald-ate-my-2gb-ssd-how-i-cap/</guid>
      <description>&lt;p&gt;I was running a little home‑lab server on a 2 GB SSD. The board was an Orange Pi Zero‑like single‑board computer, and it was juggling a personal web server, a GitLab instance, and a handful of containerised apps. After a month of steady traffic, the SSD hit 100 % on &lt;code&gt;/var&lt;/code&gt;. The culprit? &lt;code&gt;systemd‑journald&lt;/code&gt; had quietly gobbled up the whole drive.&lt;/p&gt;&#xA;&lt;p&gt;&lt;code&gt;journald&lt;/code&gt; is the default logger on most modern distros. It keeps logs in binary form under &lt;code&gt;/var/log/journal&lt;/code&gt;. By default it will keep everything until the filesystem is full, then start deleting the oldest entries. On a tiny SSD that can happen faster than you can say “disk full”.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
