#952 closed defect (fixed)

Empty list of plugins/services with 1.4.5

Reported by: blueyed Owned by: nobody
Priority: high Milestone: Munin 1.4.6
Component: node Version: 1.4.5
Severity: normal Keywords:
Cc:

Description

I've upgraded my munin-node instance on my OpenVZ hardware node to 1.4.5-1 from Debian testing, but this caused the list of services to be empty (via "telnet localhost 4949", then "list").

Downgrading to 1.4.4-1~blueyedppa2 (basically a backport of 1.4.4-1 from Debian).

There are plugins installed (quite a lot), and I can run them manually using munin-run.

Change History (9)

comment:1 Changed at 2010-08-19T00:16:57+02:00 by blueyed

btw: I've looked at the points listed in http://munin-monitoring.org/wiki/FAQ_no_graphs (after having seen a link to it in some log file).

comment:2 Changed at 2010-08-20T18:56:44+02:00 by ligne

thanks for the report.

if you try launching munin-node with the --debug option enabled, you should find that munin-node.log lists all the plugins that are being loaded, and also report any plugins that are being dropped due to errors.

comment:3 Changed at 2010-09-03T19:23:43+02:00 by 20

I can confirm that after the package was updated from 1.4.3 to 1.4.5 on RHEL5 (using the epel repository) that munin stopped listing the plugins, however fetch appears to be working normally:

Before upgrade:

$ telnet localhost 4949
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
# munin node at ###########.com
list
apache_accesses apache_processes apache_volume cpu df df_inode entropy forks fw_packets http_loadtime if_err_eth0 if_err_eth1 if_eth0 if_eth1 interrupts iostat iostat_ios irqstats load memory munin_stats netstat nfs4_client ntp_kernel_err ntp_kernel_pll_freq ntp_kernel_pll_off ntp_offset open_files open_inodes postfix_mailqueue postfix_mailvolume proc_pri processes sendmail_mailqueue sendmail_mailstats sendmail_mailtraffic swap threads uptime users vmstat yum

After:

$ telnet localhost 4949
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
# munin node at ###########.com
list

comment:4 Changed at 2010-09-04T00:08:05+02:00 by 20

The problem appears to be (for me) that in node/lib/Munin/Node/Server.pm:

!#perl
sub _list_services {
...
if (exists $nodes{$node})
...

exists $nodes{$node} evaluates to false. returning a faked array within an else statement:

!#perl
...
    } else {
        _net_write($session, join(" ", ('cpu','df_inode')));
...

confirms it.

As far as i can tell, the $node variable's value (used when storing and fetching the array of services) is identical... so what else could this be?

comment:5 Changed at 2010-09-04T00:33:41+02:00 by 20

ok, this is a stupid fix, but it works for a single node:

!#perl
sub _list_services {
    my ($session, $node) = @_;
    $node ||= $config->{fqdn};

    logger(qq{Using node: $node});

    if (exists $nodes{$node}) {
        my @services = @{$nodes{$node}};

        # remove any plugins that require capabilities the master doesn't support
        @services = Munin::Node::Utils::set_difference(\@services, \@multigraph_services)
            unless $session->{server_capabilities}{multigraph};
        @services = Munin::Node::Utils::set_difference(\@services, \@dirtyconfig_services)
            unless $session->{server_capabilities}{dirtyconfig};

        _net_write($session, join(" ", @services));
    } else {
        my @services = keys %services;
        _net_write($session, join(" ", @services));
    }
    _net_write($session, "\n");
}

comment:6 Changed at 2010-09-06T06:47:58+02:00 by 20

Solved in Server.pm:

312c312
<     $node ||= lc($config->{fqdn});
---
>     $node ||= $config->{fqdn};

The server name is forced to lowercase when the services are being set, but not when matching within sub _list_services. Please fix for next release.

comment:7 Changed at 2010-09-14T20:51:06+02:00 by ligne

it looks like this was fixed in r3404, which unfortunately predates munin-1.4.5. but it should find it's way into the next release.

comment:9 Changed at 2011-01-07T12:11:34+01:00 by jo

  • Resolution set to fixed
  • Status changed from new to closed

Closing this ticket as ligne has backported the patch. The fix will be in the next 1.4 release.

Note: See TracTickets for help on using tickets.