If you have a raspberry on some location and it must run a python script "forever" (a year, maybe two, without me being on location), how often should I reboot it? I know people are keeping them alive for a year+, but I wrote a simple script that can reboot it at given time + raspberry will automatically run the python script on boot.
8
-
1Why reboot if you don't need to? There are times when a reboot may be needed system upgrades for example. but if this is not automated I would not reboot. A reboot is not free of the risk that the system will not reboot successfully.– Steve RobillardJan 6, 2016 at 17:39
-
The one I run 24/7 has an uptime of 67 days right now, which is probably not unusual. I only reboot it for a purpose. As Steve says, why do it without any purpose?– goldilocks ♦Jan 6, 2016 at 17:53
-
4In the context of IT support, you presumably mean "in 90%" of problems reboot helps. You would not call up a customer at random and tell them to reboot now just in case ;)– goldilocks ♦Jan 6, 2016 at 18:05
-
124/7 datalogging on Arch, current uptime 260 d. Usually rebooting leads to trouble ;)– Ghanima ♦Jan 6, 2016 at 18:57
-
2Just check your logs and other growing files: logrotate will do it. SD cards have a limited lifespan on heavy loaded disk activity, maybe move /root to use external spinning drive. I added a blinking led in sync with cron and a red that lit when disk space is low and other that lit on some security log info, trimmed rsyslog to the min.– fcmJan 7, 2016 at 1:41
|
Show 3 more comments
4 Answers
I've got a couple of Pis running my Ham Radio repeater and irrigation system - realistically, I'm rebooting them maybe once every 6 months for security updates or some other "maintenance" reason; but I've not seen issues where a reboot was REQUIRED to "keep things running"
In terms of hardware, the only reason you should ever need to reboot an ARMHF-y board is firmware changes, necessary changes to ROM, or possibly new devices that must be present at boot.
For instance, adding a driver or close-to-metal kernel module and a device implementing that driver will probably need a reboot, just to tell the CPU and kernel memory mapper about the change. You can update the Linux kernel without rebooting.
In terms of software, all the major computing environments available for the Pi are *nix-like1, in that they're True Unix™ or in that they use Linux or a Linux derivative and are thus (U)nix-y.
Unix and its derivatives are designed from the bootloader up to userland to be fully scalable, portable and reliable; they were designed for servers that never or almost never undergo a hard reset (aka being fully shut down and cold-booted from scratch), and, to a lesser extent, embedded devices exactly like Raspberry Pis. Consequently, these goals indeed apply on the Pi.
This means in practice, you basically never need to reboot your Pi (or your *nix desktop PC, for that matter).
1Ignoring, for a moment, the Microsoft Windows 10: Internet Of Things Edition for the Pi, which I wish to be a practical joke but isn't.
-
2Thank you for your 2c, it helped a lot, I am now sure I will never reboot my PI. Jan 7, 2016 at 0:57
-
Kernel / device modules upgrades are the only likely causes for needing a reboot if the hardware is not changing - and it is getting possible to change modules without restarting these days if I understand things correctly.– SlySvenJan 7, 2016 at 2:17
-
@SlySven you can change modules without a reboot, just don't rely on them being fully properly functional and nondestructive– catJan 7, 2016 at 2:22
-
1
-
1@pjc50 Wow, didn't realise there'd been more recent releases for it. While I was wrong about that, I know that Win10 IoT is same core as Win10 and not CE :) Jan 7, 2016 at 16:04
With embedded "run forever" systems, periodic reboots are unnecessary. It is common to use a hardware watchdog timer to detect a system hang and reboot. I believe the watchdog timer is more valuable than a periodic reboot (the reboot probably won't work if the system is hung).
I agree with the things written before. In a theoretical situation with excellently written software with perfect error handling, no memory leaks..., a reboot won't be neccesary.
I have more than 50 PI's (all PI 3) on site, and some get rebooted weekly and others never... Almost all of the PI's are used in kiosk mode, either playing videos, displaying a website, running scripts,... User expercience is important to me and I can't afford to have a PI failing. I have a watchdog installed on all of them.
On my site, I'm using the following approach (this is only using my own experience, no scientific background :-))
PI's that run servers (Apache, SIP,...) and are only connected with an ethernet cable: I never reboot them, some of them have an uptime of almost 2 years (indeed, I didn't upgrade those)!
on the contrary, PI's that run videoloops (using OMXPlayer): I reboot those devices weekly. I've tried to not reboot them at all, but I discovered that occasionaly the video hangs without watchdog even noticing. So one would see a still image on screen. I'd say that during a one month period there was -for each of the devices- roughly a 50% chance that the video would freeze once, To minize those risks, I decided to reboot once per week and the results are acceptable: so far, after a year of weekly reboots, I only had 2 freezes (image freeze, no PI freeze). Of course I would love to eliminate those as well, but this is another topic. For those, I don't care about the impact of a reboot on the SD-card, since, if this would ever occur, it is simply putting a new SD-card and update the template with the right video.
PI's that are in client mode and display web-based user content (using Chromium, KWeb,...) with user interaction (primarily touchscreens and/or buttons): I reboot those every month and so far haven't had any issues. Maybe it was not needed to reboot them... but given those devices run scripts (Java, Node.js) and get input from other devices I thought that at some point a reboot might be needed, so I decided to go for a monthly reboot.
I realize this is not giving a direct answer to your question, but I just wanted to share some personal experience so you can -together with the other answers- judge what the best approach for your project would be.
