<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Troubleshooting on Nalar</title>
    <link>https://nalar.dev/tags/troubleshooting/</link>
    <description>Recent content in Troubleshooting on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 01 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/troubleshooting/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Find Hidden Linux Disk Usage with df, du, and lsof</title>
      <link>https://nalar.dev/find-hidden-disk-usage-with-df-du-and-lsof/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/find-hidden-disk-usage-with-df-du-and-lsof/</guid>
      <description>&lt;p&gt;A Linux filesystem can report 95% usage in &lt;code&gt;df&lt;/code&gt; while &lt;code&gt;du&lt;/code&gt; appears to account for much less. The tools are not contradicting each other: they measure different things.&lt;/p&gt;&#xA;&lt;p&gt;&lt;code&gt;df&lt;/code&gt; asks the filesystem about allocated blocks. &lt;code&gt;du&lt;/code&gt; walks visible directory entries and sums blocks reachable through those paths. The gap between those views points to several useful troubleshooting cases.&lt;/p&gt;&#xA;&lt;h2 id=&#34;start-with-the-filesystem-view&#34;&gt;Start with the filesystem view&lt;/h2&gt;&#xA;&lt;p&gt;Check filesystems and their types:&lt;/p&gt;&#xA;&lt;div &#xA;    x-data=&#34;{&#xA;        code: $el.querySelector(&#39;code&#39;).innerText&#xA;    }&#34;&#xA;    class=&#34;relative my-4 rounded-lg group&#34;&#xA;&gt;&#xA;    &lt;button&#xA;        @click=&#34;navigator.clipboard.writeText(code); $el.innerText = &#39;Copied!&#39;; setTimeout(() =&gt; $el.innerText = &#39;Copy&#39;, 2000)&#34;&#xA;        class=&#34;absolute top-2 right-2 bg-neutral-700 text-white text-xs px-2 py-1 rounded opacity-0 group-hover:opacity-100 transition-opacity&#34;&#xA;    &gt;&#xA;        Copy&#xA;    &lt;/button&gt;&#xA;    &#xA;    &lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;df -hT&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&#xA;&lt;/div&gt;&#xA;&lt;p&gt;Identify the mount that is actually full. Do not immediately scan recursively from &lt;code&gt;/&lt;/code&gt;; container mounts, network filesystems, and bind mounts can make that slow and misleading.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux Network Troubleshooting with ip, ss, dig, and curl</title>
      <link>https://nalar.dev/linux-network-troubleshooting-ip-ss-dig-curl/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/linux-network-troubleshooting-ip-ss-dig-curl/</guid>
      <description>&lt;p&gt;When a Linux service is &amp;ldquo;unreachable,&amp;rdquo; the failure can be in several different layers: the local interface, routing, a listening socket, DNS, a firewall, TLS, or the application itself.&lt;/p&gt;&#xA;&lt;p&gt;Randomly restarting services makes diagnosis harder. A better approach is to move from local state outward and identify the first layer that does not behave as expected.&lt;/p&gt;&#xA;&lt;h2 id=&#34;1-confirm-the-interface-and-address&#34;&gt;1. Confirm the interface and address&lt;/h2&gt;&#xA;&lt;p&gt;Start with the addresses configured on the host:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
