Upgrading to 5.2 when running multiple instances

[loeriver]

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?

[vince]

This one’s question for Matthew. Geez packagers are complex.

 I took a look at the postinstall sources and it seems like debian and rpm have the same code in them that looks like it tries to do the right thing but I can’t figure out how it’ll ever get to the else block that only enables the multiple instances.

Debian code is line 468 of https://github.com/weewx/weewx/blob/master/pkg/debian/postinst which is called at the bottom of the file.

[Cameron D]

I suspect it is too difficult for automated install scripts to identify multiple instances.  My process is to

1. leave the weewx.conf setting as the demo DB and the service usually disabled (not masked)
2. stop my two instances before installing.
3. upgrade.
4. check that the default service is running OK and the stop /disable it.
5. run diffs on any config file updates and if necessary apply them to my other config files.
6. manually start each service

I cannot see how the postinstall code could cope with multi-instances when based on systemd.

[matthew wall]

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!

> --
> 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 weewx-user+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/weewx-user/b5f1909e-512f-4843-9cae-427510f0dc72n%40googlegroups.com.

[vince]

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 we...@whatever.service(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.