Page 2 of 2

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Mon May 20, 2013 10:53 am
by marquettegroup
no it is not

Code: Select all

#####################################################################
# NDO2DB DAEMON CONFIG FILE
#####################################################################


lock_file=/usr/local/nagios/var/ndo2db.lock

ndo2db_user=nagios
ndo2db_group=nagios

socket_type=unix

socket_name=/usr/local/nagios/var/ndo.sock

tcp_port=5668


db_servertype=mysql
db_host=localhost
db_port=3306

db_name=nagios
db_prefix=nagios_

db_user=ndoutils
db_pass=n@gweb



## TABLE TRIMMING OPTIONS
# Several database tables containing Nagios event data can become quite large
# over time.  Most admins will want to trim these tables and keep only a
# certain amount of data in them.  The options below are used to specify the
# age (in MINUTES) that data should be allowd to remain in various tables
# before it is deleted.  Using a value of zero (0) for any value means that
# that particular table should NOT be automatically trimmed.

# Keep timed events for 24 hours
max_timedevents_age=1440

# Keep system commands for 1 week
max_systemcommands_age=10080

# Keep service checks for 1 week
max_servicechecks_age=10080

# Keep host checks for 1 week
max_hostchecks_age=10080

# Keep event handlers for 31 days
max_eventhandlers_age=44640





# DEBUG LEVEL
# This option determines how much (if any) debugging information will
# be written to the debug file.  OR values together to log multiple
# types of information.
# Values: -1 = Everything
#          0 = Nothing
#          1 = Process info
#	   2 = SQL queries

debug_level=0



# DEBUG VERBOSITY
# This option determines how verbose the debug log out will be.
# Values: 0 = Brief output
#         1 = More detailed
#         2 = Very detailed

debug_verbosity=1



# DEBUG FILE
# This option determines where the daemon should write debugging information.

debug_file=/usr/local/nagios/var/ndo2db.debug



# MAX DEBUG FILE SIZE
# This option determines the maximum size (in bytes) of the debug file.  If
# the file grows larger than this size, it will be renamed with a .old
# extension.  If a file already exists with a .old extension it will
# automatically be deleted.  This helps ensure your disk space usage doesn't
# get out of control when debugging.

max_debug_file_size=1000000

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Mon May 20, 2013 3:54 pm
by abrist
There are a large number of:

Code: Select all

root     14994 14993  0 05:11 pts/0    00:00:00 -bash
lines in the ps output. Is thin normal for this box? Try logging out and then back in, or running:

Code: Select all

killall bash

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Tue May 21, 2013 9:28 am
by marquettegroup
that is normal I guess. those were taken right after a reboot

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Tue May 21, 2013 10:16 am
by abrist
Do they get cleaned up? Init scripts could open 50+ bash shells, but it is weird that the ps entries do not reference the init scripts . . .

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Tue May 21, 2013 10:21 am
by marquettegroup
I'm assuming they aren't if they were still around after a reboot

I can reboot and let sit for like 15minutes and check that again?

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Tue May 21, 2013 1:01 pm
by abrist
If you get a chance. I would be interested if you experience the same memory errors if you attempted the upgrade again.

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Tue May 21, 2013 1:48 pm
by marquettegroup
Ok, well my problem was really when trying to do a backup prior to patching. But I went ahead and did the upgrade(which went to today's upgrade) and am working again, including being able to backup my db's

so problem resolved

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Tue May 21, 2013 2:53 pm
by slansing
Interesting, the upgrade must have kicked something off "or restarted it." Thanks for letting us know this resolved the issue, any clues as to what it was that resolved this?

Re: apparent memory issue doing upgrade to 2012R1.8

Posted: Tue May 21, 2013 2:56 pm
by marquettegroup
Not really except that maybe it "fixed" whatever problem I was having in my db that wouldn't let it backup