So I looked at the bash script Robb found, and it turns out it's specific to an
issue of the Beaglebone booting up without ethernet working in the first place.

It does not refer to ethernet stopping working while running!  So that implies
that either our beaglebone is already rebooting but the ethernet doesn't come up
(in which case this script would be wise) OR we're experiencing something else
entirely, and that script wouldn't help us.

I just checked and saw we're running / off of the built-in eMMC chip (4gb) and
I uncommented the line of /etc/fstab that causes the (8gb) microSD card to be
mounted automatically to /mnt/sd_card/  (after fixing the parameters)

So we can do logging to /mnt/sd_card/ and use it for backup purposes and
logging, because it's a removable microSD card and we don't have to worry about
ruining it.  And we should log there, so that if the ethernet port goes down we
will have a record of why that happened - assuming someone knows how to
configure it so that cached disk writes are flushed to the disk every few
minutes so that when we have to power cycle it, the logs are actually written
to disk by then.

-jake

On Sun, 14 Mar 2021, Yardena Cohen wrote:

> I'd prefer a solution that doesn't reboot. We lose the swipe log that
> way and I have to tell new people to go back and apply again for their
> cards
>
> On Sun, Mar 14, 2021 at 8:22 PM robb <sf99er@gmail.com> wrote:
>>
>> looks like a bash script to ping & reboot when necessary may fix it https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/
>>
>> On Sun, Mar 14, 2021 at 7:36 PM Jake <jake@spaz.org> wrote:
>>>
>>> [ removing omni-discuss and adding access control list in addition to two other
>>> "admin" lists i didn't know about ]
>>>
>>> this is something that has happened before.  Something about the beaglebone
>>> periodically randomly disables the ethernet port until it gets restarted.  We
>>> have never logged into the beaglebone (through its TTL serial port console for
>>> example) in order to diagnose why, we just power cycle it and it comes back up.
>>>
>>> would be interesting to save logs to a microSD card (we keep the built-in eMMC
>>> in read-only mode most of the time to prevent wear) so that we could get a clue
>>> as to what's happeneing.  Or perhaps make a process to watch for the ethernet
>>> port being powered down and restart it if that happens for whatever reason.
>>>
>>> -jake
>>>
>>> On Sun, 14 Mar 2021, robb wrote:
>>>
>>>> the beaglebone (BB) & switch to BB were sending (green lights on eth ports)
>>>> but the BB wasn't receiving (orange light...) so i rebooted the BB & it's
>>>> pinging now
>>>>
>>>> On Sun, Mar 14, 2021 at 6:51 PM Yardena Cohen <yardenack@gmail.com> wrote:
>>>>
>>>>> Did something happen to the omni door computer? I can't reach it over
>>>>> the network, even from within the building. It appears to be working,
>>>>> letting people in. I tried looking at the box, but couldn't make sense
>>>>> of the mess of cables. Maybe an ethernet got disconnected somewhere?
>>>>>
>>>>> The rest of the network is fine. Other devices on that subnet and that
>>>>> interface are reachable, but:
>>>>>
>>>>> $ ip neigh | grep 100.64.64.11
>>>>> 100.64.64.11 dev enp3s2  FAILED
>>>>> _______________________________________________
>>>>> discuss mailing list
>>>>> discuss@lists.omnicommons.org
>>>>> https://omnicommons.org/lists/listinfo/discuss
>>>>>
>>>>
>