kernow

Well-Known Member
Jul 23, 2004
1,015
61
178
cPanel Access Level
Root Administrator
After cpanel upcp ran last night several servers now getting this error:
Subroutine SNMPv1_Session::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65.
at /usr/bin/../lib64/mrtg2/SNMP_Session.pm line 594
Subroutine main::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65.
at /usr/bin/mrtg line 97
ERROR: I Quit! Another copy of mrtg seems to be running. Check /etc/mrtg/mrtg.pid
Daemonizing MRTG ...
/etc/mrtg/check-email: line 7: exim: command not found
/etc/mrtg/check-email: line 7: exim: command not found
Wednesday, 30 November 2011 at 7:20: WARNING: Problem with External get '/etc/mrtg/email-queue1 MAIL-HOST':
Expected a Number for 'in' but got ''
Stopping and restart does not fix problem :(
 
Last edited:

kernow

Well-Known Member
Jul 23, 2004
1,015
61
178
cPanel Access Level
Root Administrator
Of course when you check /etc/mrtg/mrtg.pid its empty .........
My investigations have found that the new version of MRTG does not have its cron listed in crontab -e To access use
/etc/cron.d/mrtg
I stopped MRTG from running and then put a comment in front of the cron job, not an ideal fix I know, but it has stopped the errors and the tons of emails.
Anyone have other ideas?
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
41
348
somewhere over the rainbow
cPanel Access Level
Root Administrator

kernow

Well-Known Member
Jul 23, 2004
1,015
61
178
cPanel Access Level
Root Administrator

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
41
348
somewhere over the rainbow
cPanel Access Level
Root Administrator
Too messy, this is the best fix:
Code:
rm -fv /etc/cron.d/mrtg
/etc/init.d/mrtg restart
Actually, I'm uncertain how deleting the actual cron helps a lot here. The code fix allows the cron to still work. I imagine there is indeed a purpose to the cron or it wouldn't exist? If you delete the cron, it doesn't exist anymore, so how is that a legitimate resolution?

The option I provided disables the check for IPv6 support on systems not using IPv6, and it would allow the cron to still function.
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
41
348
somewhere over the rainbow
cPanel Access Level
Root Administrator
If that is the version they provide, why do they have a non-working cron in the first place that needs removed? My belief is that it works on IPv6 enabled systems without errors. If that is the case, then the fix I've noted still applies as the error is about IPv6 not being enabled and not about whether the installation was manual or not. It's an IPv6 error after all:

Subroutine main::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65.
at /usr/bin/mrtg line 97
You are certainly welcome to disable something that comes with a product you are using such as a cron. The cron being removed rather than fixing the code prompting one portion of the cron to error (the IPv6 portion) is not the better way to fix the issue imo.
 

vicos

Well-Known Member
Apr 18, 2003
89
4
158
Well, looks like the problem is back...all 3 servers started complained early this morning. I wonder if the 2007 blog post from configserver.com is still the correct way to correct this issue?
 
Last edited:

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
41
348
somewhere over the rainbow
cPanel Access Level
Root Administrator