Recover safely from a full inode table
The useful outcome is not a green terminal. It is a clear explanation of what was checked, what the output means and what should happen next.Our specific objective is recover safely from a full inode table. …
The useful outcome is not a green terminal. It is a clear explanation of what was checked, what the output means and what should happen next.
Our specific objective is recover safely from a full inode table. A filesystem can reject writes while capacity looks healthy; inode use tells the missing half.
What you need before starting
Use a Linux host where you have sudo access and a second recovery session available. Record the hostname, distribution release, current boot time and the service window. If this is a remote production machine, keep a second SSH session open before touching authentication, networking or service configuration.
Run the diagnostic in a controlled way
Start by printing the command rather than pasting it into an unidentified shell. Confirm every hostname, path and placeholder, then execute it from a session whose output you can preserve.
df -ih- Check 1:
df -ih. Run it without piping away errors and retain the complete output.
If the command contains &&, the shell runs the next check only after the previous one exits successfully. That protects the sequence from continuing on obviously invalid input, but it does not prove the result is operationally correct.
How to interpret what you see
Read timestamps, unit names, process owners and exit codes together. A single red line may be a consequence of an earlier dependency failure, so move backwards through the journal before deciding what to restart. For this task, keep returning to the original question: A filesystem can reject writes while capacity looks healthy; inode use tells the missing half.
| Observation | Meaning | Next move |
|---|---|---|
| Expected output and exit status 0 | The diagnostic ran and returned a normal result. | Compare it with the baseline and continue to service-level verification. |
| Empty output | Possibly a healthy state, wrong scope, insufficient privilege or an overly narrow filter. | Confirm context and remove one filter at a time. |
| Permission or connection error | The observation path failed; it says nothing conclusive about the target service. | Fix access or test from an authorized vantage point. |
| Unexpected large result | The question may be too broad or the condition may be systemic. | Save evidence, narrow by time or component, and avoid impulsive bulk action. |
Verification that closes the loop
Repeat the diagnostic, inspect the relevant systemd unit, and test the service from the same network path its users take. Record the before and after outputs alongside the exact time and revision. If a user-facing path exists, test it independently; do not substitute an internal status command for customer evidence.
Failure modes worth avoiding
Do not delete logs or restart a chain of services simply to make the dashboard green. Preserve evidence, copy configuration before editing it, and use systemctl cat to see overrides.
The safest operator is not the one who never encounters failure. It is the one who preserves enough evidence to explain the failure and enough control to recover cleanly.
Rollback and handover
Restore the saved configuration, run systemctl daemon-reload when unit files changed, restart only the affected unit, then prove the original service path works. Close the task with a short note containing the symptom, diagnostic output, decision, verification and any follow-up monitoring.
This guide follows the official reference linked below. Check the documentation for the exact version running in your environment because flags, defaults and output fields can change.
Primary source: Review the official reference ↗