One thing we do running unattended BBBs is to have the watchdog package installed and tied to the hw watchdog on the AM335x, and then ensure after a reboot that you application and any networking return to their previous state (before reboot). This way even occasional unexpected crashes will generally cause a reboot and give you a downtime of no more than a couple of minutes.
We implemented this when we were getting fairly regular problems, but using the new 3.12 kernel and Debian Wheezy (and various other tweaks to our application), we have not experienced any watchdog reboots for a number of days, and have been transferring hundreds/thousands of gigabytes over usb wifi - but we'll leave it in as a backup nonetheless. On Thursday, 21 November 2013 11:33:11 UTC+13, William Hermans wrote: > > While not really unattended, I have had a BBB running Debian 7 ( wheezy ) > for as long as as 45 days with no reboots. I have accessed it via SSH, and > did some testing on it during this time. > > A couple of differences here besides the obvious is that I have it powered > via USB ( from a Windows 7 laptop ), and the Debian used is a network boot > configuration. e.g. it uses no emmc or flash media in this configuration. > > Anyhow, the BBB in this situation *would* need some form of UPS, as when > coming back up form a reboot( power blip would do the same thing ) > sometimes it can hang. Either that or a remote "switch" for resetting the > power on the device. Also as Robert mentioned above read only media would > be a requirement if you expect to get any reasonable life time out of the > device. However, the BBB *can* also boot via a USB device if that is also > an option. I'm thinking hard drive here for longevity but . . . > > > On Wed, Nov 20, 2013 at 3:07 PM, Bert Lindner <[email protected]<javascript:> > > wrote: > >> On Wednesday, November 20, 2013 10:24:24 PM UTC+1, Britton Kerin wrote: >>> >>> My BBW worked for a long time with UPS and an "industrial" SD card >>> (which >>> in theory has wear leveling and asynch shutdown tolerance) but now that >>> card >>> has gone unbootable. >>> >>> No level of SD write that should exhaust what flash is in theory capable >>> of, >>> but theory and practice... >>> >>> Any success stories out there using bb in unattended situations? >>> >>> Are the odds perhaps better if you never write the SD or eMMC at all, >>> and if so >>> is there a distribution set up to work this way (ramdisk default or the >>> like)? >>> >>> >> I use two BBBs in remote locations, running Ubuntu from eMMC. They are >> networked (I can reach them) and if really necessary I could get someone to >> power cycle them the next day, so not sure how far that counts as >> unattended. Remote hands so far have not been necessary though. Have seen >> uptimes over 3 months. >> >> They do write logs (icinga/nagios, cacti, syslog for appliance) but don't >> get rebooted very often so not sure how much this says about the likelihood >> of eMMC corruption issues. I would expect ext4 to catch most of these >> though? >> >> The limited instability I have seen with BBBs is where wireless USB >> devices are used, but even one with two USB wifi adapters has seen uptimes >> over 50 days. >> >> I have yet to experience an eMMC or SD that becomes spontaneously >> unbootable. >> >> Best, >> >> -Bert >> >> -- >> For more options, visit >> http://beagleboard.org/discuss<http://www.google.com/url?q=http%3A%2F%2Fbeagleboard.org%2Fdiscuss&sa=D&sntz=1&usg=AFQjCNEpMSpbklk_hXqEMMJhBr1sf-iMfQ> >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
