Re: How to safely power d

Dec 13, 2023 Last reply: 2 years ago 5 Replies


-=> On Wed Dec 13 02:59:00 2023, The Natural Philosopher wrote to All <=- >


> > And that is his problem. That he cant ssh in. Ive had this occasionally
> > with my remote virtual private servers. Something like a memory leak or
> > a full disk or someone DOSing it stops me getting in.
> I've been having a similar issue with one of my Pis acting as a PiHole. Every
> week or so, it totally locks up, can't SSH in, can't even get a serial
> terminal, have to hard reboot. Luckily it's actually the secondary DNS so stuff
> on my network stays up and running, but it's annoying because it also is
> connected to my UPS and a RTL-SDR that reports to FlightAware. Their emails
> telling me my feed is down is usually the first time I notice it's locked up > again.

Time to look in the error logs methinks.


IME the most *likely* cause is out of RAM, either on account of a very minor memory leak (run top and watch the memory stats) or because its on the internet and too may incomning connections are causing it to spawn too many processes.

Experience shows that there are a range of situations that can disable user access. Some of them will also disable any self-rebooting type systems you might employ.

In such cases the only option is a power cycle.

BUT if its happening regularly, the answer is to FIX THE CODE that is causing it or replace the hardware.

I remember one SPARC machine sent in to us that 'always worked for half an hour, but then stopped'

CPU fan was wrecked by dust.

Pis are cheap enough that a total swapout wont cost an ARM (sic!) and a leg so that is the easiest way to eliminate a hardware fault.

Code wise, you can disable services one at a time until its stable, or look in the log files,

Try the hardware watchdog, there's plenty of info on it, here is the first page that came to hand

formatting link

---druck

The rPi has a hardware watchdog! That is cool.

Definitely something to remember for the toolbag.

There's a cheap, rude, crude, fix that I've used for a number of units ... crontab a reboot at maybe midnight. Clears all bullshit and errors from memory and maybe only 60 seconds of downtime.

Linux/PI is good, but some kinds of errors and/or memory leaks DO seem to accumulate despite best efforts.

Crontab a root @reboot to get everything going again.

No, they dont.

Its not the Pi at fault, its not even the linux at fault, its application code that causes memory leaks.

user@heating-controller:~ $ uptime

10:33:41 up 8 days, 9:21, 1 user, load average: 0.00, 0.02, 0.03 user@heating-controller:~ $ free -m total used free shared buff/cache available Mem: 429 67 161 30 200 278 Swap: 99 0 99

No sign of memory leaks there.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required