Some possibilities in order of complexity:

   - If all the packagers are aware of whether they are being run as 'new' 
   or 'update' installations, only run enable_weewx( ) for 'new' installs. 
    Skip it for updates.


   - 
      - that at least wouldn't change anything for the update case where 
      folks previously had weewx@whatever services defined.
   

   - or itemize all the [email protected](s) on the system and use 
   'systemctl is-enabled [--quiet] foo.service' to see what is enabled, if 
   that is possible on the os you try to support, given systemd being 
   inconsistent across platforms you want to support (ugh)


   - 
      - FWIW - that seems like a lot of needless work to me.  I'd just not 
      touch systemd for updates.
   
If you wanted to make this more DRY you might call setup-daemon.sh for 
packaged installations too, which would at least centralize all the startup 
file smarts in one place if you're going to be fiddling with startup file 
logic cross-platform.....looking at that, you might need to split 
install_systemd( ) and install_sysv( ) up a little into separate 
install_whatever( ) and enable_whatever( ) routines to be able to add 
things and conditionally enable things.  Maybe.  Might be more work than 
benefit there, but os inconsistencies are painful enough that it might make 
it easier to not miss an emerging edge case.

On Monday, October 27, 2025 at 4:55:09 AM UTC-7 matthew wall wrote:

> systemd makes this difficult for many reasons. i'm sure it can be done, 
> but i'm still not sure how to do it in a way that handles all of the many 
> incompatible systemd variations.
>
> if you use init.d, then the file /etc/default/weewx specifies the weewx 
> instances and it just works.
>
> perhaps we could use /etc/default/weewx as 'truth' and have the postinst 
> run systemd-specific stuff run using whatever is declared in the defaults.
>
> the systemd masking and enabling/disabling is also fraught with 
> inconsistencies across platforms. redhat does it one way, debian does it 
> another.
>
> openvpn is another software that can make extensive use of multiple 
> instances, and in my experience that integration with systemd is still not 
> so great. its fine for one-off, manually-managed systems, but falls over 
> when it comes to upgrades and dependencies. also, there are now many 
> conflicting guides about how to set up openvpn instances.
>
> if someone has an example of software that runs multiple instances and 
> works with systemd and init.d without a ton of systemd-specific coding, 
> please post a reference!
>
>
>
> > On Oct 27, 2025, at 01:06, 'Cameron D' via weewx-user <
> [email protected]> wrote:
> > 
> > I suspect it is too difficult for automated install scripts to identify 
> multiple instances. My process is to
> > • 
> > leave the weewx.conf setting as the demo DB and the service usually 
> disabled (not masked)
> > • stop my two instances before installing.
> > • upgrade.
> > • check that the default service is running OK and the stop /disable it.
> > • run diffs on any config file updates and if necessary apply them to my 
> other config files.
> > • manually start each service
> > I cannot see how the postinstall code could cope with multi-instances 
> when based on systemd.
> > 
> > On Monday, 27 October 2025 at 4:15:05 am UTC+10 loeriver wrote:
> > Hi,
> > I upgraded weewx on Debian 12 (sudo apt update / upgrade) and noticed 
> that after this a service "weewx" was running and my 2 instances that were 
> running under 5.1 did not run anymore ("weewx@weather" and "weewx@wpm", 2 
> customized configurations).
> > 
> > Should such a case be handled by the standard update procedure or is 
> this too special?
> > 
> > -- 
> > 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/b5f1909e-512f-4843-9cae-427510f0dc72n%40googlegroups.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/453e4e8f-7c78-4a46-9850-6701880ccbbbn%40googlegroups.com.

Reply via email to