V5.0.1 and rsyslog

[Tom Hogland]

Odd change - I converted my v4 weewx-multi setup to the new v5 weewx@ service, and all is well, except logging. I have rsyslog set up to put my weewx-vp2 and weewx-tempest output into individual logs, using the .conf provided. Both services have --log-label specified and 'ps -ax' output shows them as '--log-label weewxd-vp2' and'--log-label weewxd-tempest'. The logs, however, are showing up as "weewxd-vp2.log" and "weewxd.py.log".  The actual log messages are the same - the VP2 messages are from weewxd-vp2 and the weewx-tempest messages are from weewxd.py. 

I looked through the rsyslog and weewx docs but can't find anything that sheds any light on it. Has anyone seen this behavior? This is an Ubuntu server, installed and upgraded via apt. Both instances start from the same weewx@.service file, and I can't find anything related to logging in either .conf except that log_success is false and log_failure is true.

[matthew wall]

please take a look at the wiki page "How to configure logging"

https://github.com/weewx/weewx/wiki/logging

the "weewxd.py.log" smells like a mixed up systemd configuration.  be sure that you are using the units installed by weewx (in /usr/lib/systemd) and that there are not any units in /etc/systemd leftover from v4 or inadvertently deployed somehow. also, be sure to remove anything related to weewx from /etc/init.d and the corresponding /etc/rcN.d (those will be symlinks). systemd silently ignores sysv links and files if they overlap with definitions in the unit files, but you might have something leftover from the weewx-multi script.

m

[Tom Hogland]

I went through and completely removed all the weewx leftovers from /etc/init.d, /etc/systemd etc. and restarted rsyslog. I now have *four* logs - both of the "correct" weewx-vp2 and weewx-tempest, plus weewxd.log and weewxd.py.log... weewxd-vp2.log and weexd-tempest.log appear to be the normal log messages. Weewxd.log contains an error (apparently from the weewx-sftp extension - it's from pysftp) about being unable to load keys from /var/lib/weewx/.ssh/known-hosts.

The host key error: 

Feb  6 12:20:17 tagon weewxd[1093044]: /usr/local/lib/python3.10/dist-packages/pysftp/__init__.py:61: UserWarning: Failed to load HostKeys from /var/lib/weewx/.ssh/known_hosts.  You will need to explicitly load HostKeys (cnopts.hostkeys.load(filename)) or disableHostKey checking (cnopts.hostkeys = None).

So, looks like weewx is logging correctly now - apparently the renamed entries (or a leftover in etc/init.d) were causing the original issue. I'm not using key pairs for SFTP - it uses a name/password. I created /var/lib/weewx/.ssh and copied the v4 known_hosts that I was using earlier for testing, but I can't imagine that's the right way to fix this... Also, the SFTP"report" is correctly uploading data, ad has been.

weewxd.py.log contains output from the weatherflowudp extension - the initial field maps, then "listening" lines. Looks like that's the only Tempest driver, and it's 4+ years old. Anyone familiar with this driver that might have an idea why it's not logging as part of weewx?

[vince]

On Tuesday, February 6, 2024 at 5:28:13 PM UTC-8 Tom Hogland wrote:

weewxd.py.log contains output from the weatherflowudp extension - the initial field maps, then "listening" lines. Looks like that's the only Tempest driver, and it's 4+ years old. Anyone familiar with this driver that might have an idea why it's not logging as part of weewx?

Sure. It is 'not' part of weewx (core).

It is a user-written extension add-on 'to' weewx that uses a different 'weatherflowudp' string in its log messages.

Your weewx multi likely has this uncommented in it...

$template WEEWX_LOGFILE,"/var/log/weewx/%programname%.log"
if $programname startswith 'wee' then ?WEEWX_LOGFILE
if $programname startswith 'wee' then stop

I'd add the following (untested).....

if $programname startswith 'weatherflowudp' then ?WEEWX_LOGFILE
if $programname startswith 'weatherflowudp' then stop

You will likely need to stop/restart rsyslog for it to take effect and possibly also the weewx@tempest instance.