<div dir="ltr">fwiw, building just briefly lost power & 100.64.64.11 is still pingable after reboot<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 15, 2021 at 12:36 PM Jake <<a href="mailto:jake@spaz.org">jake@spaz.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">mine is not a solution!  just a method of increasing our awareness of the<br>
situation.<br>
<br>
Robb it sounds like your link might be appropriate for our situation after all<br>
but I always like to have more information before trying a particular solution.<br>
<br>
Does anyone know how to turn on logging and direct the logs to the appropriate<br>
place?  and cause periodic filesystem flush?<br>
<br>
On Sun, 14 Mar 2021, robb wrote:<br>
<br>
> fwiw, the building lost all mains power a day or two ago which may have<br>
> caused it to reboot w/o eth. regardless, Jake's solution seems like the<br>
> easiest solution<br>
><br>
> On Sun, Mar 14, 2021 at 11:45 PM Jake <<a href="mailto:jake@spaz.org" target="_blank">jake@spaz.org</a>> wrote:<br>
><br>
>> So I looked at the bash script Robb found, and it turns out it's specific<br>
>> to an<br>
>> issue of the Beaglebone booting up without ethernet working in the first<br>
>> place.<br>
>><br>
>> It does not refer to ethernet stopping working while running!  So that<br>
>> implies<br>
>> that either our beaglebone is already rebooting but the ethernet doesn't<br>
>> come up<br>
>> (in which case this script would be wise) OR we're experiencing something<br>
>> else<br>
>> entirely, and that script wouldn't help us.<br>
>><br>
>> I just checked and saw we're running / off of the built-in eMMC chip (4gb)<br>
>> and<br>
>> I uncommented the line of /etc/fstab that causes the (8gb) microSD card to<br>
>> be<br>
>> mounted automatically to /mnt/sd_card/  (after fixing the parameters)<br>
>><br>
>> So we can do logging to /mnt/sd_card/ and use it for backup purposes and<br>
>> logging, because it's a removable microSD card and we don't have to worry<br>
>> about<br>
>> ruining it.  And we should log there, so that if the ethernet port goes<br>
>> down we<br>
>> will have a record of why that happened - assuming someone knows how to<br>
>> configure it so that cached disk writes are flushed to the disk every few<br>
>> minutes so that when we have to power cycle it, the logs are actually<br>
>> written<br>
>> to disk by then.<br>
>><br>
>> -jake<br>
>><br>
>> On Sun, 14 Mar 2021, Yardena Cohen wrote:<br>
>><br>
>>> I'd prefer a solution that doesn't reboot. We lose the swipe log that<br>
>>> way and I have to tell new people to go back and apply again for their<br>
>>> cards<br>
>>><br>
>>> On Sun, Mar 14, 2021 at 8:22 PM robb <<a href="mailto:sf99er@gmail.com" target="_blank">sf99er@gmail.com</a>> wrote:<br>
>>>><br>
>>>> looks like a bash script to ping & reboot when necessary may fix it<br>
>> <a href="https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/" rel="noreferrer" target="_blank">https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/</a><br>
>>>><br>
>>>> On Sun, Mar 14, 2021 at 7:36 PM Jake <<a href="mailto:jake@spaz.org" target="_blank">jake@spaz.org</a>> wrote:<br>
>>>>><br>
>>>>> [ removing omni-discuss and adding access control list in addition to<br>
>> two other<br>
>>>>> "admin" lists i didn't know about ]<br>
>>>>><br>
>>>>> this is something that has happened before.  Something about the<br>
>> beaglebone<br>
>>>>> periodically randomly disables the ethernet port until it gets<br>
>> restarted.  We<br>
>>>>> have never logged into the beaglebone (through its TTL serial port<br>
>> console for<br>
>>>>> example) in order to diagnose why, we just power cycle it and it comes<br>
>> back up.<br>
>>>>><br>
>>>>> would be interesting to save logs to a microSD card (we keep the<br>
>> built-in eMMC<br>
>>>>> in read-only mode most of the time to prevent wear) so that we could<br>
>> get a clue<br>
>>>>> as to what's happeneing.  Or perhaps make a process to watch for the<br>
>> ethernet<br>
>>>>> port being powered down and restart it if that happens for whatever<br>
>> reason.<br>
>>>>><br>
>>>>> -jake<br>
>>>>><br>
>>>>> On Sun, 14 Mar 2021, robb wrote:<br>
>>>>><br>
>>>>>> the beaglebone (BB) & switch to BB were sending (green lights on eth<br>
>> ports)<br>
>>>>>> but the BB wasn't receiving (orange light...) so i rebooted the BB &<br>
>> it's<br>
>>>>>> pinging now<br>
>>>>>><br>
>>>>>> On Sun, Mar 14, 2021 at 6:51 PM Yardena Cohen <<a href="mailto:yardenack@gmail.com" target="_blank">yardenack@gmail.com</a>><br>
>> wrote:<br>
>>>>>><br>
>>>>>>> Did something happen to the omni door computer? I can't reach it over<br>
>>>>>>> the network, even from within the building. It appears to be working,<br>
>>>>>>> letting people in. I tried looking at the box, but couldn't make<br>
>> sense<br>
>>>>>>> of the mess of cables. Maybe an ethernet got disconnected somewhere?<br>
>>>>>>><br>
>>>>>>> The rest of the network is fine. Other devices on that subnet and<br>
>> that<br>
>>>>>>> interface are reachable, but:<br>
>>>>>>><br>
>>>>>>> $ ip neigh | grep 100.64.64.11<br>
>>>>>>> 100.64.64.11 dev enp3s2  FAILED<br>
>>>>>>> _______________________________________________<br>
>>>>>>> discuss mailing list<br>
>>>>>>> <a href="mailto:discuss@lists.omnicommons.org" target="_blank">discuss@lists.omnicommons.org</a><br>
>>>>>>> <a href="https://omnicommons.org/lists/listinfo/discuss" rel="noreferrer" target="_blank">https://omnicommons.org/lists/listinfo/discuss</a><br>
>>>>>>><br>
>>>>>><br>
>>><br>
>><br>
><br>
</blockquote></div>