SDCard -- install here and deploy there?

On 22/10/2020 01:07 pm, Markus Robert Kessler wrote:


If you're using Raspbian, it will probably work - other OSs may not.
Why not hedge your bets (it could be an RPi complete failure) and get a  
new one to set up from scratch.

On Thu, 22 Oct 2020 13:33:56 +0100, Chris Elvidge wrote:


100
SDCard  


That would be wise. A Zero is not exactly expensive... Also "didn't
come back from a reboot" is a bit vague. Is that just waiting after
issuing a reboot command or after a shut down and power cycle? Has it
been power cycled? Has the SD card been reseated and the power
cycled? Is there a micro SD to SD card adpater in use?

On Thu, 22 Oct 2020 14:13:25 +0100 Dave Liquorice wrote:



Hi, what I've done in short:

I start a python script via crontab every 10 minutes which reads I2C data  
from a BME280 sensor. This script calculates the temperature, relative  
humidity and relative air pressure and sends it to a webserver.

This works perfectly.

To be on the safe side I make / made a reboot every night. From this the  
questioned machine didn't return, now. I see in the log that the last  
transmission was ok, then the reboot was started and the connection was  
lost. So, I doubt that the machine completely broke down. Most likely the  
SDCard gave up.

So, I also have to re-think if it is a good idea to make daily reboots  
even though the resources are not locked or eaten up. Maybe one reboot  
per week will also do?

P.S. I'd rather prefer to use "Raspberry Zero / WLAN" only for  
installation, since it has only Wifi and the network there is cable based.

Best regards,

Markus

  Re: Re: SDCard -- install here and deploy there?
  By: Markus Robert Kessler to All on Thu Oct 22 2020 05:35 pm

 > To be on the safe side I make / made a reboot every night. From this the

I know I am not helping, but rebooting "just because" is bad practice.

If anything, reboot the service you need to reboot. And it is still bad.

Much better to have a watchdog or something email you if there is any issue.

On Thu, 22 Oct 2020 14:48:10 +1300 Richard Falken wrote:



Hi,

on my RPI-3 I used to have a watchdog service. But by some reason the  
system hung instead of doing a hardware-reboot. Maybe there was a kernel  
module mismatch. So, I switched it off.

Besides this, a watchdog may put your SDCard in a state where an fsck is  
demanded for. So, the system does not start non-interactively next time.

best regards,

Markus

On 22/10/2020 23:08, Markus Robert Kessler wrote:


I agree with that. The majority of downtime across my dozen Pis are  
issues after reboots. It ranges from network dropping out while booting,  
to hardware not being ready, and of course the SD card throwing a wobbly.

If the system is remote, I would not automatically reboot. If it needs  
rebooting, have someone there power cycle it, and wait until it has  
rebooted in case it needs another power cycle.



You can configure it to do an automated fsck on every reboot, which  
doesn't need any interaction. It can add a minute or two to the boot  
time, and you need to check the logs regularly as if the card is  
starting to get dodgy it can struggle on fixing itself up to the point  
where it dies completely. What you should do is replace it immediately  
there is any doubt.

But the best solution (if not using a Pi A or Zero) is to use something  
other than SD for the root filing system.

---druck

On 2020-10-22, Richard Falken



Go easy on him, he probably started out as a Microsoft vict^H^H^H^Huser.

On Fri, 23 Oct 2020 17:16:40 +0000 Charlie Gibbs wrote:



Vict-what? -- Victim?

At work I use to boot my machines only every few months and some even  
once per year. For headless servers this is sufficient. But these have  
typically 16 GB of RAM or even more.

We are talking about a "Raspberry A" with 256 MB (MegaByte). Under load  
this amount will be eaten up soon. That was one of the reasons for  
inventing repeated reboots. On more sophisticated RPIs with 1 GB this is  
not necessary of course.

Markus

On 24/10/2020 11:39, Markus Robert Kessler wrote:


??? WTF ???




Good grief...

On Sat, 24 Oct 2020 10:39:35 -0000 (UTC)



    Reboots to cure memory leaks ? IOW reboots as a workaround for bad
programming! That has never been acceptable in my book since times when
256Mb was a dream as disc capacity.

    I ran a 256Mb Rpi for a long time as router, DNS, DHCP, VPN and
asterisk server, it never needed regular reboots. These days I need more
CPU and better networking in the router (gigabit PPPoE takes a fairly fast
processor).

On 24/10/2020 12:19, Ahem A Rivet's Shot wrote:


Yeah, back in the real world it's an optimisation problem. Is it more  
efficient to reboot a server or invest time debugging leaky code. Time  
is money.

On Sat, 24 Oct 2020 12:43:03 +0100, Pancho wrote:



But seeing that the code is leaky is dead simple: just run top and look  
at the display every so often.

On 24/10/2020 12:50, Martin Gregorie wrote:


Yes, it is often dead simple to see that code doesn't work, however  
fixing it....

On Sat, 24 Oct 2020 13:54:44 +0100, Pancho wrote:



Yes, seeing that a bit of code doesn't work is simple, but realising that  
it might be a memory leak, not so much unless its Java, when you get told  
in no uncertain terms what happened if your program hit the size limit on  
the JVM's memory allocation pool.

I'm always surprised by the number of people don't know that 'top'  
exists, let alone understand what it can show you.
  

On Sat, 24 Oct 2020 12:43:03 +0100



    Out here in my bit of the real world if we create a service that we
can't stop leaking then we arrange to restart the *service* periodically
because our customers look on unexpected reboots with great disfavour. They
like their expensive servers to be serving not rebooting.

On 24/10/2020 13:07, Ahem A Rivet's Shot wrote:

Very good point

On 24/10/2020 13:07, Ahem A Rivet's Shot wrote:


No doubt. However many customers like cheap code delivered fast.

I have tended to work on projects where rapid development time was  
crucial and once developed it was often cheaper to throw hardware at  
problems, rather than developer time.

On Sat, 24 Oct 2020 12:43:03 +0100, Pancho wrote:



I this type of thinking is precisely why there is so much bad code with  
security vulnerabilities in the wild.

If you cant afford to do it right how on earth can you afford the losses  
from a data  breach?

On 24/10/2020 14:03, alister wrote:



Data Breach? pah!, peanuts. I could show you how to write code to really  
lose money.