**** BEGIN LOGGING AT Tue May 18 02:59:56 2021 May 18 03:03:32 And if there is a specific chip I can use, WP (write protected) might get in the way... May 18 03:36:16 GenTooMan: Oh well. May 18 03:37:14 I guess guessing is not so easy when EEPROM chips, write protect, and i2c are involved, e.g. esp. when uploading source onto the MC is not allowed. May 18 11:13:16 Cannot initiate the connection to repos.rcn-ee.com:80 (2600:3c00::f03c:91ff:fe37:6ad5). - connect (101: Network is unreachable) Could not connect to repos.rcn-ee.com:80 (45.33.2.10), connection timed out [IP: 45.33.2.10 80] <<< Is this normal for now? May 18 11:18:43 Oh well, I think my wifi source is far off. It is working now. May 18 11:59:31 @zmatt: do you take on paid consulting work? May 18 13:25:37 m May 18 13:32:19 m2u kremlin May 18 14:26:14 TonyTheLion: no May 19 01:00:53 Sorry for earlier. I bugged out on a poor wifi signal. May 19 01:03:04 Anyway... https://pastebin.com/nHfD7U7y is what I cannot configure to work directly w/ Python3 right now. Does anyone have any insight as to how to handle this odd sensor w/ pyserial? May 19 01:03:24 ... May 19 01:03:37 It is almost like pyserial is for Python only and not Python3. May 19 01:04:22 I should have tried out the apt install python3-serial instead. Dang it. May 19 01:04:32 Oh well...no issue. May 19 01:07:00 Well...if you take a gander, please send guidance or insight. May 19 01:07:16 Or laugh at how silly it is...either/or. May 19 01:07:27 No offense to serial lovers. May 19 01:16:36 Oh! The sensor is an outdated TFmini. May 19 01:17:47 I have it wired to the BBB via sys_5v for power to the level shifter, uart, and gnd. Then, 3.3v to the BBB from its sys_5v source. May 19 01:19:10 It is gettin' icky. Is this a pyserial issue or Python3 or does my explanation of the connections not do justice? May 19 01:20:03 I guess patience on the pyserial side is okay w/ me but Python3 will move on like it is moving. May 19 01:20:13 POSIX! May 19 01:20:33 Anyway...quit again. May 19 01:20:41 quit = quiet May 19 01:24:14 b instead of hex? May 19 01:24:17 Hmm. May 19 01:25:02 Anyway...off to do battle w/ this Lidar. May 19 01:25:24 'checking back often!' May 19 01:30:19 what's the best way to check for an restart critical user applications? I'm thinking of a cron job that runs every couple minutes but that seems a little hacky May 19 02:15:26 masdf: normally you'd run them as systemd services, which have configurable auto-restart policy May 19 02:21:10 e.g. you can configure when the service should be restart (e.g. only when it crashes or just always), whether to have a delay before restarting May 19 02:23:35 and put the service into "failed" state if it restarts too many times in too short time (both configurable) to stop trying to restart it if it just keeps crashing on restart. you can also configure that the system should be automatically rebooted if this happens May 19 02:26:04 yeah should have been more clear... I'm using sysv May 19 02:26:32 As far as I know sysv doesn't have nifty restart features May 19 02:27:34 so why are you using sysvinit instaed of systemd? :P May 19 02:29:08 having an init system that can actually properly supervise service is kinda useful May 19 02:29:43 I'm stuck with it for this particular application, not my choice May 19 02:31:12 there are obviously also standalone utils for supervising a service... e.g. djb's daemontools May 19 02:34:02 and one of the first google results for "daemon supervisor" is this thing: http://supervisord.org/ May 19 02:36:20 that's a very good point, I'll check it out May 19 02:37:34 one nice thing systemd does is put each service into its own control group to track any processes spawned by it, so that all of them get killed when the service is stopped/restarted May 19 02:37:51 without that it can be possible to accumulate stray child processes, depending on what the service is doing May 19 02:40:18 my app uses socket connections, maybe daemontools or something similar could clean those up May 19 02:40:33 sockets automatically close when a process exits May 19 02:40:51 or rather, when the last process that has an open file descriptor for that socket exits May 19 02:41:08 yeah but I've seen some weird behavior with END_WAIT holding the socket for a while and preventing me from restarting it May 19 02:41:45 maybe that's just something I should handle with my socket config May 19 02:42:05 TIME_WAIT you mean? May 19 02:42:18 set the SO_REUSEADDR socket option May 19 02:43:05 tbh I passed this problem off to a contractor so hopefully he fixed it lol... I'll need to investigate May 19 02:45:41 basically it just has to do with how TCP works May 19 02:46:48 yeah I remember when I was debugging that it seemed to be a legacy thing for signal propagation May 19 02:47:07 ?? May 19 02:47:11 so the host on the other end of the connection had time to find out the socket was closing May 19 02:47:27 I mean, that's not a "legacy thing" May 19 02:48:14 though perhaps the default MSL of 1 minute is a bit excessive May 19 02:48:44 yeah I mean 'legacy' as in not how we would do it today lol May 19 02:49:36 but in any case, for my purposes I'd be better off with no delay at all May 19 02:49:52 not sure that's true, I think that would require adding another protocol phase to closing the connection May 19 02:51:10 anyway, not being able to start listening on the same port again while there are still TIME_WAIT connections can be fixed by setting SO_REUSEADDR on the socket before binding May 19 02:51:26 that's very helpful, thanks! May 19 02:51:39 Hey! Me, me, me! May 19 02:51:43 Me next! May 19 02:52:01 Did you guys look over the odd source for the TFmini? May 19 02:53:56 guys? May 19 02:53:59 Gals? May 19 02:54:05 Hello? May 19 02:54:18 echo, echo, echo? May 19 02:54:19 Forget it! May 19 02:54:53 WHy is this internet so darn lonely? May 19 02:55:18 Aw! May 19 02:55:41 'back to the ole drawing board!' **** ENDING LOGGING AT Wed May 19 02:59:57 2021