Hi Michael,

Tom confirmed in the incident that it is a bug and has provided a fix. I will roll it in as soon as I can. W00t!

Cheers!

---
pablo


On 2025-11-17 12:05, '[email protected]' via weewx-user wrote:
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 [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 [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/48532b96-eb34-46d1-b2e3-5b4190347f01n%40googlegroups.com <https://groups.google.com/d/msgid/weewx-user/48532b96-eb34-46d1-b2e3-5b4190347f01n%40googlegroups.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/a00fb91d-be8f-41c5-9516-e8b840a10aab%40hillsandlakes.com.

Reply via email to