more precisely, weewxd should stop if it fails to connect. if loop-on-init is enabled, then it should restart.
for robustness it might be good to have retries at the transaction/query level, then if n retries fail, weewxd fails and stops (or restart if loop-on-init is enabled) its been a long time since i was in the mysql code, but i thought that is what we implemented. and systemd hacks (or sysv init hints) wont handle the case where mysqld/whatever is remote (which was the primary use case for using mysqld/whatever instead of sqlite) m On Nov 17, 2025, 08:11, at 08:11, Tom Keffer <[email protected]> wrote: >John, time to give it a rest. You were heard. > >I would suggest focusing on the restart mechanism. The executable >weewxd >should restart if a database connection cannot be made. If that is not >the >case, then that's a bug. Document it and let us know. > >On Mon, Nov 17, 2025 at 4:57 AM John Smith <[email protected]> >wrote: > >> >> >> On Mon, 17 Nov 2025 at 23:09, matthew wall <[email protected]> >wrote: >> >>> on the contrary, cameron's comment is exactly on point. systemd >unit >>> files are *not* conf files, so they may be replaced when you >update/upgrade >>> the weewx package. the pattern for customizing systemd units is the >.d >>> pattern. >>> >> >> Why is everyone trying to dream up the worst configuration possible >that >> someone maybe sort of kind of might do? >> >> The core issue is very very simple weeWX no longer starts on boot up >with >> out intervention, be it changes to the SystemD file or manually >starting it. >> >> >>> adding a dependency in systemd is a hack, not a real fix, for a >number of >>> reasons: >>> >> >> It would immediately restore previous functionality. >> >> >>> 1) it does not fix the problem for every operating system and init >system >>> >> >> That's a straw man argument, the only problem is with the order that >> SystemD starts things. >> >> >>> 2) it is a dependency that does not apply to every installation, >>> >> >> Since not every installation has SystemD involved this is again a >straw >> man argument. >> >> >>> 3) it is a dependency that is not part of weewx and that could >change >>> depending on a non-weewx component of the system >>> >> >> Have we moved on to buzz word bingo or something? >> >> >>> just as we have to minimize python module and os dependencies, we >have to >>> minimize init dependencies. otherwise long-term support and >robustness >>> suffer. a lot. we could take the route of not having any deb/rpm >> >> >> More straw man arguments, a slight change to service file will NOT >> increase your support work load, it will decrease it because people >won't >> complain about weeWX not starting on system boot. >> >> >>> packages for weewx, and let someone else create those to include in >>> debian or redhat or whatever. but some time ago we chose to do >them, to >>> make life easier for users and so that users could have weewx >updates more >> >> >> What's any of that got to do with the PR I made? weeWX doesn't start >when >> the OS starts... You are creating support headaches for yourself by >trying >> to defend a point absent logic and there isn't any data showing how 2 >extra >> lines in a SystemD service file will be even be noticed let alone >> detrimental... >> >> >>> frequently (if they choose) than the os releases. we have been >fairly >>> successful in keeping weewx packages robust wrt to the changes >between os >>> releases, and consistent across multiple operating systems (and >their >>> different uses of systemd, for that specific init system) >>> >> >> There aren't any problems in an any other init system, so why keep >making >> straw man arguments without actually addressing my comments based on >> evidence rather than going off on frequent tangents? >> >> >>> is not the fix to make weewx retry mysql/maria/postgres connections >and >>> do nothing else until that connection is successful? >>> >> >> Finally something on topic at last, but then you immediately brought >up a >> red herring by including pgSQL... >> >> -- >> You received this message because you are subscribed to the Google >Groups >> "weewx-user" group. >> To unsubscribe from this group and stop receiving emails from it, >send an >> email to [email protected]. >> To view this discussion visit >> >https://groups.google.com/d/msgid/weewx-user/CAGTinV4xKmhq%2BtXgN%2B1awU3LYpZPi%3DS%3DvU8h39TV5PRny0vHzA%40mail.gmail.com >> ><https://groups.google.com/d/msgid/weewx-user/CAGTinV4xKmhq%2BtXgN%2B1awU3LYpZPi%3DS%3DvU8h39TV5PRny0vHzA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > >-- >You received this message because you are subscribed to the Google >Groups "weewx-user" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to [email protected]. >To view this discussion visit >https://groups.google.com/d/msgid/weewx-user/CAPq0zEDGCS8kHdZwK1xr9P6rZFyjddL003GZ7LPZr97T4eGcMA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/de63240c-5d72-48d2-b200-f3b79ad6807a%40gmail.com.
