[mrtg] SNMP_Session error

Edwin A. Epstein III ed at rhinobee.com
Thu Jan 5 22:11:37 CET 2017


Hi Nick,

I'm not sure how I can help with the Perl issues, but we run MRTG in daemon mode on OpenBSD. I'm not a super expert in Linux/BSD, but I believe in either the startup script is in /etc/init.d or /etc/rc.d and written in bash. They should be compatible, I hope, and here is a copy to get you pointed in the right direction. From the beginning I decided to run it in daemon mode to ease up on those cron messages. There is still plenty of logging in /var/log/mrtg.log (MRTG) and /var/log/daemon (RC/Init) to give you insight into operations and any issues. The logging can be set to several different levels (see MRTG manual), and is currently only logging the configurations and base operations. The script "works" and has been working for over a year with minimal issues (once in awhile MRTG has hung up), but I'm not an expert in bash so no warranties :) 

Separate from that, I wrote my own guardian script to inspect MRTG during run time and keep it running, but that is outside of what I can give you today. 

In OpenBSD (which is similar to FreeBSD) I kind of cheated and just used a cron entry at boot time, but in Linux you would use chkconfig to make sure services start. OpenBSD is a different beast to say the least :)

Our MRTG environment is located in /etc/mrtg/*, which is not standard. Please modify your paths accordingly. 

The cron tab entry for root on OpenBSD:
"@reboot /etc/rc.d/mrtg start"

/etc/rc.d/mrtg (Any comments from others in the list are appreciated):

##########################################################

#!/bin/sh
#
# $OpenBSD: mrtg.rc, v1.1 03/11/2016 Ed Epstein III
#   based on mrtg.rc from source
#
# v1.1 03/11/2016
# - Host Names fixed
# v1.0 11/24/2015
# - Added check,reload,start,and stop functions
# - Logging of operations to /var/log/daemon
# - Reload performs -HUP

#
# Current version 


# Definitions for the daemon. Note that the --daemon has been moved to flags 
daemon="/usr/local/bin/mrtg"
daemon_flags="/etc/mrtg/mrtg.cfg --daemon --logging /var/log/mrtg.log --debug=conf,base"

# Standard rc include
. /etc/rc.d/rc.subr

# Get our host name
hostname=`hostname`

# Regular expression used to test for the PID, but is not used
pexp="/usr/bin/perl -w ${daemon}${daemon_flags:+ ${daemon_flags}}"
# The following is used instead to locate the PID
#PID=`ps -aux | grep mrtg.cfg | grep -v grep | awk '{print $2}'`

# Check for PID
rc_check() {
  PID=`ps -aux | grep mrtg.cfg | grep -v grep | awk '{print $2}'`
  RETVAL=$?;
  if [[ ! -z ${PID} ]]; then
    logdate=`date "+%b %e %H:%M:%S"`
    logline="${hostname} mrtg[${PID}]: MRTG checked and is running"
    echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
    return 0
  else
    logdate=`date "+%b %e %H:%M:%S"`
    logline="${hostname} mrtg[${PID}]: MRTG checked and is NOT running"
    echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
    return 1
  fi  
}

# Stops it, and not gracefully. Investigate better signal to send to
# MRTG during operation for graceful shutdown.
rc_stop() {
  PID=`ps -aux | grep mrtg.cfg | grep -v grep | awk '{print $2}'` 
  RETVAL=$?;

  if [[ ! -z ${PID} ]]; then
    kill ${PID}
    RETVAL=$?;
      if [[ $RETVAL -eq 0 ]]; then
        logdate=`date "+%b %e %H:%M:%S"`
        logline="${hostname} mrtg[${PID}]: MRTG daemon stopped"
        echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
        return 0
      else
        logdate=`date "+%b %e %H:%M:%S"`
        logline="${hostname} mrtg[${PID}]: MRTG daemon failed to stop"
        echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
        return 1
      fi
  fi


}

rc_pre() {
  logdate=`date "+%b %e %H:%M:%S"`
  logline="${hostname} mrtg[${PID}]: Attempting to start MRTG"
  echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
}

# Starts MRTG if not started already
rc_start() { 

  logdate=`date "+%b %e %H:%M:%S"`
  logline="${hostname} mrtg[${PID}]: Starting MRTG Daemon"
  echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon

  PID=`ps -aux | grep mrtg.cfg | grep -v grep | awk '{print $2}'`
  RETVAL=$?;
  if [[ ! -z ${PID} ]]; then
    logdate=`date "+%b %e %H:%M:%S"`
    logline="tigger mrtg[${PID}]: MRTG daemon already started"
    echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
   return 0
  else
    PID=`/usr/local/bin/mrtg /etc/mrtg/mrtg.cfg --daemon --logging /var/log/mrtg.log --debug=conf,base`
    RETVAL=$?;
    if [[ $RETVAL -eq 0 ]]; then
        logdate=`date "+%b %e %H:%M:%S"`
        logline="${hostname} mrtg[${PID}]: MRTG daemon started successfully"
        echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
        return 0
      else   
        logdate=`date "+%b %e %H:%M:%S"`
        logline="${hostname} mrtg[${PID}]: MRTG daemon failed to start"  
        echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon        
        return 1
      fi
  fi
  


}

rc_reload() {

  PID=`ps -aux | grep mrtg.cfg | grep -v grep | awk '{print $2}'`
  kill -HUP ${PID}
  RETVAL=$?;
  if [[ $RETVAL -eq 0 ]]; then
    logdate=`date "+%b %e %H:%M:%S"`
    logline="${hostname} mrtg[${PID}]: MRTG daemon has been reloaded"        
    echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
    return 0
  else 
    logdate=`date "+%b %e %H:%M:%S"`
    logline="${hostname} mrtg[]: MRTG daemon failed to reload"  
    echo -n "${logdate} ${logline}"'\n'  >> /var/log/daemon
    return 1
  fi

}

rc_cmd $1

################################

 



Sincerely, 

Edwin A Epstein, III 
Rhinobee Internet Services 
707.237.7504 ext 209 
707.737.0288 Mobile

----- Original Message -----
From: "mrtg-request" <mrtg-request at lists.oetiker.ch>
To: "mrtg" <mrtg at lists.oetiker.ch>
Sent: Tuesday, January 3, 2017 8:55:48 AM
Subject: mrtg Digest, Vol 117, Issue 2

Send mrtg mailing list submissions to
	mrtg at lists.oetiker.ch

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
or, via email, send a message with subject or body 'help' to
	mrtg-request at lists.oetiker.ch

You can reach the person managing the list at
	mrtg-owner at lists.oetiker.ch

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mrtg digest..."


Today's Topics:

   1. Re: SNMP_Session error (Niall O'Reilly)
   2. Fw:  SNMP_Session error (Nick Price)
   3. Re: SNMP_Session error (Niall O'Reilly)


----------------------------------------------------------------------

Message: 1
Date: Tue, 03 Jan 2017 14:41:53 +0000
From: "Niall O'Reilly" <niall.oreilly at ucd.ie>
To: "mrtg at lists.oetiker.ch" <mrtg at lists.oetiker.ch>
Subject: Re: [mrtg] SNMP_Session error
Message-ID: <A2C341BD-47DF-4C60-9D0A-06A117BE12C1 at ucd.ie>
Content-Type: text/plain; format=flowed

On 2 Jan 2017, at 11:33, Nick Price wrote:

> HI All
>
> I have just install fedora 25 with all the updates for it and perl to 
> latest versions
>
> I installed mrtg (2.17.4) and when I run it I get in the crontab mail 
> box
>
> Subroutine SNMP_Session::pack_sockaddr_in6 redefined at 
> /usr/share/perl5/vendor_perl/Exporter.pm line 66.
> at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_Session.pm line 149.
> Subroutine SNMP_Session::unpack_sockaddr_in6 redefined at 
> /usr/share/perl5/vendor_perl/Exporter.pm line 66.
> at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_Session.pm line 149.
> Subroutine SNMPv1_Session::pack_sockaddr_in6 redefined at 
> /usr/share/perl5/vendor_perl/Exporter.pm line 66.
> at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_Session.pm line 604.
> Subroutine SNMPv1_Session::unpack_sockaddr_in6 redefined at 
> /usr/share/perl5/vendor_perl/Exporter.pm line 66.
> at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_Session.pm line 604.
>
> I have copied the SNMP_Sessions.pm from mrtg folder to the perl folder 
> and I still get this.
>
> My last install of fedora was ver 22 and doing this cured it this time 
> it hasn't
>
> Any ideas as this is flooding the mailbox every 5 minutes

   Since you ask ...

   Whenever I've seen the kind of messages you've shown above, they've 
been fallout
   from sloppy initialization code in one or a couple of Perl modules 
resulting in
   repeated definitions of the same subroutine.  For me, there were two 
reasons for
   this to be inconsequential; first: any subsequent code re-definition 
seemed to be
   compatible with the original one, so the application just worked; 
second: I always
   used to run MRTG in daemon mode in order to avoid the repeated 
startup overhead
   involved in using cron to launch each sampling run.

   You don't say whether MRTG is otherwise working correctly for you, so 
I don't
   know whether the re-definitions have any other effect than flooding 
your e-mail.

   If reducing the noise is all you need to do, three options occur to 
me, of which
   tracking down the root of the problem and eliminating the 
redefinitions is the
   "most correct", but likely the most troublesome.  Moreover, this 
option may be
   subverted by any future upgrade of one or other of the collection of 
packages
   on which MRTG depends.

   MRTG's daemon mode will eliminate repeated startup of MRTG, and so 
avoid
   repeated emission of startup-time warnings.  You'll need to configure 
daemon
   mode in your MRTG configuration file, and provide or obtain a 
suitable init
   script or systemd configuration for starting and stopping the MRTG 
daemon.

   Another approach, which I've used on occasion for some other 
application, is
   to invoke a wrapper script from cron; this might redirect error 
output to a
   temporary file, somehow check for a "real" failure, and only generate 
output
   for cron to send on by mail in case such a failure occurred.

   I'ld happily let you have the scripts I used to use in a previous job 
for each
   of these approaches, but have some connectivity trouble just now and 
so am
   without the necessary access.

   I hope this is of some help.

   Best regards,
   Niall O'Reilly



------------------------------

Message: 2
Date: Tue, 3 Jan 2017 15:17:16 +0000
From: Nick Price <np121 at hotmail.com>
To: "mrtg at lists.oetiker.ch" <mrtg at lists.oetiker.ch>
Subject: [mrtg] Fw:  SNMP_Session error
Message-ID:
	<AM5PR0901MB14903B1CE054EBFA1FFAA126E36E0 at AM5PR0901MB1490.eurprd09.prod.outlook.com>
	
Content-Type: text/plain; charset="iso-8859-1"


I use contrab because the output of every device is sent to a different folder, so that the owner of that device is the only person (except mrtgadmin) that can view it.


I have never set up mrtg as a daemon and not sure how to achieve the same results as with crontab.


What has changes in the later version of perl that wasn't in fedora 22 where I didn't have this problem


Any help setting it up to run as a daemon or a cure for the error would help please.


I'm not a Linux expert nor do I write perl, I just install and use


Nick


________________________________
From: mrtg <mrtg-bounces+np121=hotmail.com at lists.oetiker.ch> on behalf of Niall O'Reilly <niall.oreilly at ucd.ie>
Sent: Tuesday, January 3, 2017 3:41 PM
To: mrtg at lists.oetiker.ch
Subject: Re: [mrtg] SNMP_Session error

On 2 Jan 2017, at 11:33, Nick Price wrote:

> HI All
>
> I have just install fedora 25 with all the updates for it and perl to
> latest versions
>
> I installed mrtg (2.17.4) and when I run it I get in the crontab mail
> box
>
> Subroutine SNMP_Session::pack_sockaddr_in6 redefined at
> /usr/share/perl5/vendor_perl/Exporter.pm line 66.
> at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_Session.pm line 149.
> Subroutine SNMP_Session::unpack_sockaddr_in6 redefined at
> /usr/share/perl5/vendor_perl/Exporter.pm line 66.
> at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_Session.pm line 149.
> Subroutine SNMPv1_Session::pack_sockaddr_in6 redefined at
> /usr/share/perl5/vendor_perl/Exporter.pm line 66.
> at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_Session.pm line 604.
> Subroutine SNMPv1_Session::unpack_sockaddr_in6 redefined at
> /usr/share/perl5/vendor_perl/Exporter.pm line 66.
> at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_Session.pm line 604.
>
> I have copied the SNMP_Sessions.pm from mrtg folder to the perl folder
> and I still get this.
>
> My last install of fedora was ver 22 and doing this cured it this time
> it hasn't
>
> Any ideas as this is flooding the mailbox every 5 minutes

   Since you ask ...

   Whenever I've seen the kind of messages you've shown above, they've
been fallout
   from sloppy initialization code in one or a couple of Perl modules
resulting in
   repeated definitions of the same subroutine.  For me, there were two
reasons for
   this to be inconsequential; first: any subsequent code re-definition
seemed to be
   compatible with the original one, so the application just worked;
second: I always
   used to run MRTG in daemon mode in order to avoid the repeated
startup overhead
   involved in using cron to launch each sampling run.

   You don't say whether MRTG is otherwise working correctly for you, so
I don't
   know whether the re-definitions have any other effect than flooding
your e-mail.

   If reducing the noise is all you need to do, three options occur to
me, of which
   tracking down the root of the problem and eliminating the
redefinitions is the
   "most correct", but likely the most troublesome.  Moreover, this
option may be
   subverted by any future upgrade of one or other of the collection of
packages
   on which MRTG depends.

   MRTG's daemon mode will eliminate repeated startup of MRTG, and so
avoid
   repeated emission of startup-time warnings.  You'll need to configure
daemon
   mode in your MRTG configuration file, and provide or obtain a
suitable init
   script or systemd configuration for starting and stopping the MRTG
daemon.

   Another approach, which I've used on occasion for some other
application, is
   to invoke a wrapper script from cron; this might redirect error
output to a
   temporary file, somehow check for a "real" failure, and only generate
output
   for cron to send on by mail in case such a failure occurred.

   I'ld happily let you have the scripts I used to use in a previous job
for each
   of these approaches, but have some connectivity trouble just now and
so am
   without the necessary access.

   I hope this is of some help.

   Best regards,
   Niall O'Reilly

_______________________________________________
mrtg mailing list
mrtg at lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg

mrtg Info Page - lists.oetiker.ch Mailing Lists<https://lists.oetiker.ch/cgi-bin/listinfo/mrtg>
lists.oetiker.ch
To see the collection of prior postings to the list, visit the mrtg Archives. Using mrtg: To post a message to all the list members, send email to ...



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oetiker.ch/pipermail/mrtg/attachments/20170103/c4a57846/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 03 Jan 2017 16:55:30 +0000
From: "Niall O'Reilly" <niall.oreilly at ucd.ie>
To: "mrtg at lists.oetiker.ch" <mrtg at lists.oetiker.ch>
Subject: Re: [mrtg] SNMP_Session error
Message-ID: <785D1E15-A127-4911-AC4A-E328E6C1E7EB at ucd.ie>
Content-Type: text/plain; format=flowed; markup=markdown



On 3 Jan 2017, at 15:17, Nick Price wrote:

> I use contrab because the output of every device is sent to a 
> different folder, so that the owner of that device is the only person 
> (except mrtgadmin) that can view it.

   I guess you're specifying the folder in the MRTG configuration file.
   If so, you can continue to do this in the same way.

   Do you use a single configuration file, or a separate one for each 
device,
   or some other approach?

> I have never set up mrtg as a daemon and not sure how to achieve the 
> same results as with crontab.

   It's explained in the section headed "RunAsDaemon" in the 
configuration reference
   (http://oss.oetiker.ch/mrtg/doc/mrtg-reference.en.html).  The 
'Target' sections
   can remain unchanged.

> What has changes in the later version of perl that wasn't in fedora 22 
> where I didn't have this problem

   I can't be sure, as I'm not currently running any OS from the RedHat 
family
   (RHEL, CentOS, Fedora).  I have only Debian/Ubuntu and FreeBSD.  I 
suspect
   that a Perl module has been installed in two places and references to 
both
   are somehow (either explicitly or implicitly) being made by MRTG.  
This can
   come about through an accidental interaction between your approach to 
managing
   the packages involved and the release-engineering practice of the 
package
   and distribution developers.  Unfortunately, there is a risk of such 
an
   interaction at any version transition; I'm not sure it's useful to 
ask what
   has changed at this particular milestone.

> Any help setting it up to run as a daemon or a cure for the error 
> would help please.

   If you have just one configuration file and a corresponding single 
crontab
   entry, the transition to daemon mode is fairly simple.  You just need 
to
   obtain and install a starter script and follow the instructions for
   "RunAsDaemon".

> I'm not a Linux expert nor do I write perl, I just install and use

   I understand. 8-)

   Best regards,
   Niall O'Reilly



------------------------------

Subject: Digest Footer

_______________________________________________
mrtg mailing list
mrtg at lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg


------------------------------

End of mrtg Digest, Vol 117, Issue 2
************************************
(null)



More information about the mrtg mailing list