sneader

Well-Known Member
Aug 21, 2003
1,178
57
178
La Crosse, WI
cPanel Access Level
Root Administrator
After last night's upcp, some of our servers are sending error emails every 5 minutes, for example:

SUBJECT: Cron <[email protected]> LANG=C LC_ALL=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg --lock-file /var/lock/mrtg/mrtg_l --confcache-file /var/lib/mrtg/mrtg.ok

BODY: Subroutine SNMP_Session::pack_sockaddr_in6 redefined at /usr/share/perl5/Exporter.pm line 67.
at /usr/bin/../lib64/mrtg2/SNMP_Session.pm line 149.
Subroutine SNMPv1_Session::pack_sockaddr_in6 redefined at /usr/share/perl5/Exporter.pm line 67.
at /usr/bin/../lib64/mrtg2/SNMP_Session.pm line 604.
Subroutine main::pack_sockaddr_in6 redefined at /usr/share/perl5/Exporter.pm line 67.
at /usr/bin/mrtg line 102.
Subroutine main::unpack_sockaddr_in6 redefined at /usr/share/perl5/Exporter.pm line 67.
at /usr/bin/mrtg line 102.
Subroutine main::sockaddr_in6 redefined at /usr/share/perl5/Exporter.pm line 67.
at /usr/bin/mrtg line 102.
ERROR: I Quit! Another copy of mrtg seems to be running. Check /etc/mrtg/mrtg.pid
Daemonizing MRTG ...
In looking at the upcp logs, I see these interesting lines

[20130321.003315] [14909] ---> Package mrtg.x86_64 0:2.16.2-5.el6 will be updated
[20130321.003315] [14909] ---> Package mrtg.x86_64 0:2.16.2-7.el6 will be an update
[20130321.003315] [14909] ---> Package mrtg-libs.x86_64 0:2.16.2-5.el6 will be updated
[20130321.003315] [14909] ---> Package mrtg-libs.x86_64 0:2.16.2-7.el6 will be an update
--snip--
[20130321.003316] [14909] mrtg x86_64 2.16.2-7.el6 system-base 694 k
[20130321.003316] [14909] mrtg-libs x86_64 2.16.2-7.el6 system-base 95 k
--snip--
[20130321.003341] Updating : mrtg-libs-2.16.2-7.el6.x86_64 11/74
--snip--
[20130321.003345] Updating : mrtg-2.16.2-7.el6.x86_64 19/74
--snip--
[20130321.003433] Cleanup : mrtg-2.16.2-5.el6.x86_64 38/74
--snip--
[20130321.003433] Cleanup : mrtg-libs-2.16.2-5.el6.x86_64 44/74
--snip--
[20130321.003439] Verifying : mrtg-2.16.2-7.el6.x86_64 9/74
--snip--
[20130321.003439] Verifying : mrtg-libs-2.16.2-7.el6.x86_64 24/74
--snip--
[20130321.003439] Verifying : mrtg-libs-2.16.2-5.el6.x86_64 59/74
--snip--
[20130321.003439] Verifying : mrtg-2.16.2-5.el6.x86_64 74/74
--snip--
[20130321.003439] [14909] mrtg.x86_64 0:2.16.2-7.el6
[20130321.003439] [14909] mrtg-libs.x86_64 0:2.16.2-7.el6
Spent some time Googling, consulting with others, and haven't got very far. Just curious if someone else out there has already seen and fixed this, before I beat myself up too hard.

As a data point, MRTG does seem to still be functioning... just concerned about the errors every 5 minutes.

- Scott
 

PenguinInternet

Well-Known Member
PartnerNOC
Jun 20, 2007
190
22
68
Cardiff, UK
cPanel Access Level
DataCenter Provider
Twitter
At a guess I'd say that you've got mrtg running as a daemon and the upgrade to the mrtg RPM has added the mrtg cron process in to run every 5 minutes, hence the warning that it is already running - we've seen this pretty often on various servers. Just remove /etc/cron.d/mrtg if you do run mrtg as a daemon
 

sneader

Well-Known Member
Aug 21, 2003
1,178
57
178
La Crosse, WI
cPanel Access Level
Root Administrator
Thanks for the reply... I forgot to update this thread after finally figuring things out. Indeed you were correct, we had to remove /etc/cron.d/mrtg and restart mrtg. However, that did not stop all the other errors.

I wound up upgrading to MRTG 2.17, which was a project in itself that I will outline below. That STILL didn't eliminate all the errors, but some Google-foo led me to a website that outlined some minor code changes to a couple MRTG perl files, and that finally made MRTG happy.

Upgrading to MRTG 2.17 didn't work by just simply doing a "yum update mrtg", even after removing the * after perl from /etc/yum.conf. I wound up getting it via RepoForge, as follows:

  1. Make a backup copy of /etc/mrtg/mrtg.cfg
  2. Set up the RepoForge repository to get the more up-to-date package.
    Instructions for installing it are at Using RepoForge . Once it is installed, edit /etc/yum.repos.d/rpmforge.repo, and change any line that says "enabled = 1" to "enabled = 0" to make sure that the new repositories will never be used accidentally in situations where the regular repositories should be used.
  3. Remove the existing mrtg-libs package (this is necessary before installing the new mrtg package, because the libraries are built into the 2.17 package rather than being a separate package). "rpm -e mrtg-libs --nodeps" will do this.
  4. Install mrtg 2.17 with the following command "yum --enablerepo=rpmforge-extras update mrtg"
  5. Restore the backup of your mrtg.cfg file (if needed)

After upgrading MRTG, I still needed to do some search/replace code changes as outlined at: https://odesk.by/archives/1169

The "before" code didn't always match what we had, but I still went with the "after" code and it resolved the errors.

Lastly, I had to remove /etc/cron.d/mrtg and restart mrtg with "service mrtg restart" No errors!

- Scott
 

sneader

Well-Known Member
Aug 21, 2003
1,178
57
178
La Crosse, WI
cPanel Access Level
Root Administrator
After rebooting one of the servers that I made these changes to, MRTG would not start. Error message:

Starting MRTG: Undefined subroutine &SNMP_Session::pack_sockaddr_in6 called at /usr/bin/../lib64/mrtg2/SNMP_Session.pm line 150.
BEGIN failed--compilation aborted at /usr/bin/../lib64/mrtg2/SNMP_Session.pm line 154.
Compilation failed in require at /usr/bin/../lib64/mrtg2/SNMP_util.pm line 44.
BEGIN failed--compilation aborted at /usr/bin/../lib64/mrtg2/SNMP_util.pm line 44.
Compilation failed in require at /usr/bin/../lib64/mrtg2/MRTG_lib.pm line 662.
After much Google-foo, I stumbled upon this 4 year old thread:

#45 ([patch] ERROR Subroutine SNMPv1_Session::AF_INET6)

I made changes to my config as shown under "comment4" and restarted MRTG and it worked! Basically I did this:

1) Found 2 instances of "Socket6->import(qw(inet_pton getaddrinfo));"
2) Changed them to: "Socket6->import(qw(pack_sockaddr_in6 inet_pton getaddrinfo));"

MRTG is happy again.

- Scott
 

sneader

Well-Known Member
Aug 21, 2003
1,178
57
178
La Crosse, WI
cPanel Access Level
Root Administrator
Looks like the article I linked to is no longer visible. The edits I mention need to be done to /usr/lib64/mrtg2/SNMP_Session.pm

- Scott