apparent memory issue doing upgrade to 2012R1.8

[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

[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

[marquettegroup]

that is normal I guess. those were taken right after a reboot

[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 . . .

[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?

[abrist]

If you get a chance. I would be interested if you experience the same memory errors if you attempted the upgrade again.

[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

[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?

[marquettegroup]

Not really except that maybe it "fixed" whatever problem I was having in my db that wouldn't let it backup