If a user chooses a database other than sqlite, this is an active decision, 
and the database must be provided by the user—unlike the default sqlite. 
That said, I would expect there to be a defined behavior for weewx if the 
database connection cannot be established. This behavior should be 
described in the documentation, and if the reality differs from the 
desired/documented behavior, there is a bug that needs to be fixed. The 
user who has actively chosen an alternative to sqlite should be able to 
judge whether they need to take additional measures to ensure that the 
application works under the given circumstances.
Pablo Sanchez schrieb am Montag, 17. November 2025 um 16:43:04 UTC+1:

> Hi everyone,
>
> Database puke here.
>
> Nearly all applications are database applications. For any db application, 
> the question is, what to do if the database is no longer available?  Do we 
> fail or go into a retry-loop until the db comes back.
>
> It is a design decision and I would also say an operational decision. That 
> is, do we want to encumber the end-user with restarting database 
> dependencies too? In this case, weewx? Generally, no.
>
> Personally, I would continue with the design decision to do retry. This 
> way the end-users, who by and large I would say are non-technical, have 
> less to worry about. It would also solve any boot-up synchronization issues.
>
> I captured forensics of what I witnessed (the weewxd not reconnecting on 
> db becoming available) here - https://github.com/weewx/weewx/issues/1036
>
> Thx! 
>
> ---
> pablo
>
>
>
> On 2025-11-17 08:53, matthew wall wrote:
>
> 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>
>  
> <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 
> visithttps://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/48532b96-eb34-46d1-b2e3-5b4190347f01n%40googlegroups.com.

Reply via email to