Your message dated Mon, 11 Feb 2019 19:19:58 +0100
with message-id <[email protected]>
and subject line Re: Bug#918105: munin-plugins-core: postgres_connections_
return zeros after 2.0.44-1~bpo9+1 upgrade
has caused the Debian Bug report #918105,
regarding munin-plugins-core: postgres_connections_ return zeros after
2.0.44-1~bpo9+1 upgrade
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
918105: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918105
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: munin-plugins-core
Version: 2.0.44-1~bpo9+1
Severity: normal
Dear Maintainer,
I have noticed that postgres_connections_* graphs started rendering zero
height graphs after upgrading munin from Streth Backports. This is
output example:
```
# munin-run postgres_connections_ALL
active.value 0
idle.value 0
idletransaction.value 0
unknown.value 0
waiting.value 0
```
Please see screenshot attached.
There's no way numbers should be actually zero - this is production
system, and this reproduced on three different machines.
Other plugin, like postgres_connections_db, still works fine:
```
munin-run postgres_connections_db
db_v2.value 29
postgres.value 0
template1.value 0
```
There are no relevant error messages in munin-node.log.
-- System Information:
Debian Release: 9.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages munin-plugins-core depends on:
ii munin-common 2.0.44-1~bpo9+1
ii perl 5.24.1-3+deb9u5
Versions of packages munin-plugins-core recommends:
ii libnet-snmp-perl 6.0.1-2
Versions of packages munin-plugins-core suggests:
ii acpi 1.7-1+b1
ii conntrack 1:1.4.4+snapshot20161117-5
pn default-mysql-client <none>
ii ethtool 1:4.8-1+b1
ii hdparm 9.51+ds-1+deb9u1
pn libcache-cache-perl <none>
ii libdbd-mysql-perl 4.041-2
ii libdbd-pg-perl 3.7.4-1~pgdg90+1
ii libhttp-date-perl 6.02-1
ii liblwp-useragent-determined-perl 1.07-1
ii libnet-dns-perl 1.07-1
ii libnet-ip-perl 1.26-1
pn libnet-irc-perl <none>
pn libnet-ldap-perl <none>
ii libnet-netmask-perl 1.9022-1
pn libnet-telnet-perl <none>
ii libxml-parser-perl 2.44-2+b1
ii libxml-simple-perl 2.22-1
ii lm-sensors 1:3.4.0-4
ii logtail 1.3.18
ii net-tools 1.60+git20161116.90da8a0-1
ii python3 3.5.3-1
ii ruby 1:2.3.3
ii smartmontools 6.5+svn4324-1
-- no debconf information
--- End Message ---
--- Begin Message ---
Package: munin
Version: 2.0.45-1
Hello Vincas,
Am Mon, 11 Feb 2019 10:23:24 +0200
schrieb Vincas Dargis <[email protected]>:
> > Could you please check, whether reverting one of the following changes
> solves
> > the problem for you?
> > * https://github.com/munin-monitoring/munin/commit/af8d9dabdb65e
> > * https://github.com/munin-monitoring/munin/commit/6ffb285d1a6cf
>
> It seems that after latest 2.0.45 upgrade this plugin started showing
> values without any manual changes.
Good!
Recently I applied a potential fix for the above problem to upstream.
> "Waiting for lock" is strange naming though, I would expect it more like
> "Idle" or "Idle in transaction", as I would imagine waiting for lock a
> contention event, and I doubt it's the case, but I am not PostgreSQL expert
> here.
Same for me (being a non-expert).
If you have a specific proposal: please share it!
> It would be nice to have some sort of integration tests for these kind of
> plugins to test correctness.
Yes, indeed, I (as part of upstream) would feel much better with plugin-related
tests, but I did not come up with a good approach. Any input is welcome!
Cheers,
Lars
--- End Message ---
