From sf99er at gmail.com Mon Apr 5 21:38:36 2021 From: sf99er at gmail.com (robb) Date: Mon, 5 Apr 2021 21:38:36 -0700 Subject: [sudo-access] [sudo-discuss] can't reach door computer In-Reply-To: References: Message-ID: 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 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 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 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 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 > >> 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 at lists.omnicommons.org > >>>>>>> https://omnicommons.org/lists/listinfo/discuss > >>>>>>> > >>>>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake at spaz.org Mon Apr 5 21:50:57 2021 From: jake at spaz.org (Jake) Date: Mon, 5 Apr 2021 21:50:57 -0700 (PDT) Subject: [sudo-access] [sudo-discuss] can't reach door computer In-Reply-To: References: Message-ID: yes the front door computer is accessible and says it's been up for 28 minutes which is strange because the router that i connected to it through has only been up for 19 minutes. anyway it's working. your email went out to four lists in addition to a couple of people directly. I feel weird about messages going out to so many lists. -jake On Mon, 5 Apr 2021, robb wrote: > 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 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 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 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 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 >>>> 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 at lists.omnicommons.org >>>>>>>>> https://omnicommons.org/lists/listinfo/discuss >>>>>>>>> >>>>>>>> >>>>> >>>> >>> >> > From yardenack at gmail.com Tue Apr 6 01:57:45 2021 From: yardenack at gmail.com (Yardena Cohen) Date: Tue, 6 Apr 2021 01:57:45 -0700 Subject: [sudo-access] [sudo-discuss] can't reach door computer In-Reply-To: References: Message-ID: The router takes much longer to boot up. Even the bios takes a few minutes waiting for shit to time out. It's still that old dell desktop because the proper hardware died last year and nobody has replaced it. On Mon, Apr 5, 2021, 9:50 PM Jake wrote: > yes the front door computer is accessible and says it's been up for 28 > minutes > > which is strange because the router that i connected to it through has only > been up for 19 minutes. anyway it's working. > > your email went out to four lists in addition to a couple of people > directly. > I feel weird about messages going out to so many lists. > > -jake > > > On Mon, 5 Apr 2021, robb wrote: > > > 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 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 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 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 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 at 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 at lists.omnicommons.org > >>>>>>>>> https://omnicommons.org/lists/listinfo/discuss > >>>>>>>>> > >>>>>>>> > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: