Had this problem when my storage filled up
this post was submitted on 14 Sep 2026
6 points (100.0% liked)
Selfhosted
63012 readers
2064 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
It sounds to me like ssdh may have stopped working. That may explain why you can't ssh into your server but pings still respond. I have a Raspberry Pi4 and a Pi5 and have had similar issues in the past.
I would probably approach this issue by writing a small script that checks every so often if the process sshd is still alive and if not restart sshd. Maybe SystemD can so something similar but I am not familiar with SystemD.
Edit: A quick and simple script looks like this
#!/bin/sh
# Check if `sshd` process is running; If not running, `pgrep` returns
# an exit status of '1' and restarts `sshd`
pgrep 'sshd' > /dev/null || systemctl restart sshd
Make the script executable with chmod +x /home/user_name/sshd_check
Add the following line to /etc/crontabs/root to run the script every 15 minutes
*/15 * * * * /home/user_name/sshd-check
I don't use SystemD but I am pretty sure systemctl restart sshd is correct, otherwise it can be changed to whatever your operating system uses to control services
Thanks, I'll try this. What speaks against this is that all my services turn unreachable, and those do not rely on ssh access. But still worth a try.
Aah you did mention that, my eyes just decided to skip that when I read your post.
This reminds me of another issue I ran into but I use Alpine Linux so I don't know if it's a distribution specific issue. I'll share the issue and workaround solution anyways as something to consider.
Networking on Alpine Linux is controlled by a process called networking and for reasons I don't understand and can't see by any logs, it just stops working. I can't ssh or access the reverse proxy port. I don't remember if ping was working or not as it's been a while since I dealt with it now.
My work around was to have a script on my server ping a known location and restart networking if it couldn't ping out. If a second ping after restarting the process failed, it would then restart the device. This script would run every 15 minutes.
It's a bandage solution that doesn't solve the problem but it does keep my server running. However it seems like pings still work with your server so you might need to get creative in how you test your server's connectivity.
systemd will try to save any kernel panics in pstore via systemd-pstore, if it's enabled in your kernel. I'd check /var/lib/systemd/pstore and see if anything in there on the next boot.
Can you elaborate on ping "running"? Do you get actual icmp replies coming back? Because there's no code path I can imagine where a ping would cause hdd activity (on a normally running system).
If ssh times out (and you don’t do anything fancy with the firewall), then it's not sshd dead, it's sshd not being able to respond. Grab a tcpdump for dst port 22 from your local machine while RPi is stuck and see if you get any replies whatsoever or it's just retransmits going into the void.
My first rough suspicion would be ram abuse. Something eats up all ram and the system locks up and semi-dies. Pstore would have OOMs. You could run a local script for telemetry recording too to see if ram use spikes up before the system gets unresponsive.
I had similar behavior caused by file corruption, and what I believe was a faulty SD card. Also on an RPi. Thankfully I had most of my services and configs backed up and on another disk.
I was also digging through system journals and log files, tracking down what the heck was failing. Eventually I found some system files which were corrupted, and re flashed the SD. Ended up happening a couple times before I replaced it.