Weewx-Multi not quite working

[Tom Hogland]

I haven't been able to find any record of this behavior. Adjusted my working weewx with VP2 to use weewx-multi, added the second config, etc. all per the docs, naming/databases/configs etc. Running "/etc/init.d/weewx start" fires up both instances, both are working correctly (updating webroot files etc.). Problem is, "weewx status" shows neither is running, and "weewx stop" says the same, however "weewx restart" closes and restarts them both without issue. Specifying either instance name does the same - status or stop says not running, restart works fine. Looking at the ps listing - both are there and working fine... pid files in /run are also correct. I don't see any issues in the script itself.

I imagine there's something simple to this but I can't find it - anyone know what's causing the failure to see the correct status?  Or is there a simple solution that I just failed to dig out of the docs/forum?

-Tom

[Doug Jenkins]

Tom:

I had trouble with this configuration back 2 years ago when I ran both a SDR and a Acurite instance of WeeWX using a reporting instance to report the results for both.

What I did was I created a shell script for each instance (eg wx-sdr, wx-acurite, wx-rpt) and used cron to execute each at reboot. Here is a snippet of my script that I used:

#WX_SDR Instance execution

HOME=/home/weewx

CONF_FILE=/home/weewx/conf/wx_sdr.conf LOG_FILE=/home/weewx/logs/wx_sdr.log

echo "using $CONF_FILE"

cd $HOME

./bin/weewxd $CONF_FILE >> $LOG_FILE

WeeWX will start an instance and I just had it report its results in a log. You can modify this to use logrotate as prescribed in the wiki

logging · weewx/weewx Wiki (github.com)

hope this helps!

Doug Jenkins

largoweather.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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/7a1420e8-3bc2-4b79-9696-581174e3c2aen%40googlegroups.com.

[Tom Hogland]

This is what I tried first - rather than using weewx-multi I duplicated the original weewx script to weewx-tempest, changed everything VP2-related to Tempest (database, config, etc.) and tried to start it. Nothing at all - no error, no log, just nothing. If I started the Tempest instance, then the VP2 one wouldn't start. I'm sure "something" was blocking/locking something but never could find it, and since weewx-multi was designed to handle this I went that route.

[vince]

In the absence of logs, nobody is going to be able to help you much.

[matthew wall]

tom,

which operating system are you using, and which release?

which version of weewx are you using?  more importantly, which weewx-multi script are you using?

if you are not using weewx-multi from the latest weewx release (4.7.0), could you grab weewx-multi from github and see if that behaves any differently from the weewx-multi currently on your system?

m

[Tom Hogland]

I'm using 4.7 installed on Ubuntu server - I downloaded the github version of weewx-multi since the Ubuntu package doesn't include it. There's no log info - it just doesn't work correctly when trying to stop or report status, while it *does* work correctly when starting or restarting. Just walked back through the script, thinking maybe there was a typo in PIDFILE or related, but nothing looks amiss. So, I re-grabbed a new copy from github and saved it. Didn't touch anything in it - set all the variables in /etc/default/weewx-multi and tried again - same result. Restart worked, but status says it isn't running. Checked /run/tempest.pid and it correlates to the actual pid of the running tempest instance. Killed all the running weewx instances, deleted the pid files, started them back up with weewx start vp2 and weewx start tempest, both are running, both pids are the same as the pid files created, and yet it still says neither is running when querying status...

This is truly weird, although since it's running and doing all it's weather goodness it's not an emergency or anything. I might let it stew for a few days and look at it again this weekend.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/nZjzDRm6dtY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/146ab416-728b-4ce3-bdb5-e1b366b52efbn%40googlegroups.com.

[cric...@pobox.com]

I've been doing something similar for years, and one or a couple of tricks is to specify the

pid file location and name.  In my case, I use a single directory, but multiple config files,

multiple skin directories, and separate archive directories and database names.

I use a perl script to do the restarting (can't stand systemd).

Chris

[Tom Hogland]

Poking at this a bit more, I'm wondering if it's Debian/Ubuntu specific. The /etc/init.d/weewx script calls /usr/bin/weewxd in Debian systems, which is a shell that somehow calls the "real" weewxd in /usr/share/weewx. I'm not 100% sure how it does that, as nothing actually refers to that location - just /usr/bin, /etc/weewx and /run. I changed the /etc/default/weewx-multi to change WEEWXD_BINDIR to /usr/share/weewx and once I did calling "/etc/init.d/weewx stop vp2" (or tempest) both worked correctly to stop and show status. However, they fail to start it back up - import configobj error. Added WEEWX_BIN=/usr/bin/weewxd and left BINDIR at /usr/share/weewx and same behavior.

Started everything manually - "python3 /usr/share/weewx/weewxd --pidfile=/run/weewx-vp2.pid /etc/weewx/vp2.conf" and no errors - just a string of loop packets. Digging in the archives here I found references to mis-matched python version causing this error, and I have both python 2.7 and 3.8 installed. Changed link for python from python2 to python3 and a new error - unable to locate /home/weewx/bin/weewxd. I changed the /etc/init.d/weewx script - commented out the original variables for WEEWX_BINDIR wec. and pasted in the correct ones from /etc/defaults/weex-multi but same error... There's now no reference to /home in /etc/init.d/weewx, /etc/defaults/weewx-multi or /usr/bin/weewxd and yet that's the error.

Again, confusion reigns supreme. Time to put things back and let it rest, I think.

[matthew wall]

perhaps some explanation of intent would help.

the deb/rpm packages have entrypoints for weewx utilities at /usr/bin/wee*.  these are shell scripts that invoke the actual weewx 'binaries' in /usr/share/weewx.  there are two reasons for these: (1) they ensure that the weewx utilities are automatically in every user's path, and (2) they provide a mechanism for customizing/overriding the python implementation used to invoke weewx.  customizing is done using /etc/default/weewx (i know, this probably should be /etc/sysconfig on redhat systems.  sorry.  and it is /etc/defaults/weewx on *bsd systems).  the variables are WEEWX_PYTHON, WEEWX_BINDIR, WEEWX_BIN, and WEEWX_CFG.

the weewx-multi script is functionally one level up from that.  it has a WEEWX_BINDIR that indicates where the weewx binaries are located, as well as WEEWX_INSTANCES, WEEWX_USER, WEEWX_CFGDIR, and WEEWX_RUNDIR variables.  it will work with any type of weewx installation (setup.py, deb, rpm, etc), although it does currently have debian tendencies (all of the lsb stuff).  the variables can be overridden in /etc/default/weewx-multi so that you do not have to modify the weewx-multi script itself.

finally, it is my intent to push the capabilities of weewx-multi into the 'standard' weewx init.d script, and make the package installers detect whether to deploy an rc script or a systemd unit file.  that is complicated by the fact that (1) there are (were) different conventions for init scripts on redhat vs debian vs suse vs *bsd, and (2) we now have to keep systemd happy too, which means doing a variation of the weewx unit file that has weewx-multi capabilities (perhaps kinda like openvpn has done).

m

[Graham Eddy]

using systemd, i start weewx instances independently. my weewx@.service file uses the unit name as the weewx conf file e.g. # systemctl start weewx@gw1000 → starts ‘weewxd gw1000.conf’ (and similarly for pidfiles etc). i also keep separate logs for instances e.g. weewxd gw1000.conf —log-name=weewx-gw1000 with rsyslog routing weewx-gw1000 to /var/log/weewx/gw1000.log.

you can wildcard the unit name e.g. # systemctl status weewx@*

⊣ Graham Eddy ⊢

[graha...@gmail.com]

i have created a cookbook at https://weather.geddy.id.au/weewx-systemd.html on how i create multiple instances (vp2, gw1000 and another for reporting) for my platform needs (debian, systemd, run-as-weewx, weewx-ramdisk) in the hope of influencing how matthew implements weewx-multi within weewx product, acknowledging matthew is looking to also support other os flavours, legacy rc subsystem, etc.. also, handy to jog my memory too!

cheers

[Tom Hogland]

Wow - impressive, and quite customized. Amazing report skin as well. 

I should probably do something similar with the "other way" so it's documented as well.