fwiw, building just briefly lost power & 100.64.64.11 is still pingable after reboot

On Mon, Mar 15, 2021 at 12:36 PM Jake <jake@spaz.org> wrote:
mine is not a solution!  just a method of increasing our awareness of the
situation.

Robb it sounds like your link might be appropriate for our situation after all
but I always like to have more information before trying a particular solution.

Does anyone know how to turn on logging and direct the logs to the appropriate
place?  and cause periodic filesystem flush?

On Sun, 14 Mar 2021, robb wrote:

> fwiw, the building lost all mains power a day or two ago which may have
> caused it to reboot w/o eth. regardless, Jake's solution seems like the
> easiest solution
>
> On Sun, Mar 14, 2021 at 11:45 PM Jake <jake@spaz.org> wrote:
>
>> 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
>>>>>>>
>>>>>>
>>>
>>
>