So something tells me that your system is running fine, except for 250mb audit logs per hour.
Main Topics
Browse All TopicsWe are receiving thousands of entries in the audit logs, all the
same. Below is a representative sample. This is happening on
a two node RAC with ORACLE 10.2.0.3 and Linux 2.6.18-53.el5.
The end result is that we are rotating
20MB audit logs every 4-5 minutes.
What is basically happening here is that we are recording failed
system calls (per IA instructions). The ones shown below represent,
mostly, a failure to open a file. Since this is happening many times
per second, essentially on the same set of files, what I'm looking
for is some kind of process that is attempting to access these
Oracle files. Note that whatever is doing this is running as root.
From the research so far, it almost seems like some options in Oracle
were not installed. Which may be just fine, but the issue remains that
we are getting thousands of records being recorded in the audit logs.
There is obviously some Oracle process (running as root) that is
making "open" system calls to these files which results in a system
call failed audit log.
Is there any possibility that the Oracle OEM console is generating
this?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
thanks for the response. below is the /etc/inittab file
#
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
#
# Author: Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.
# Modified for RHS Linux by Marc Ewing and Donnie Barnes
#
# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
id:3:initdefault:
# System initialization.
si::sysinit:/etc/rc.d/rc.s
# DIACAP (GEN000020,GEN000040)
~:S:wait:/sbin/sulogin
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
# Trap CTRL-ALT-DELETE
# DIACAP (LNX00580)
#ca::ctrlaltdel:/sbin/shut
# When our UPS tells us power has failed, assume we have a few minutes
# of power left. Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdo
# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin
# Run gettys in standard runlevels
1:2345:respawn:/sbin/minge
2:2345:respawn:/sbin/minge
3:2345:respawn:/sbin/minge
4:2345:respawn:/sbin/minge
5:2345:respawn:/sbin/minge
6:2345:respawn:/sbin/minge
# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefd
S0:2345:respawn:/sbin/aget
h1:35:respawn:/etc/init.d/
h2:35:respawn:/etc/init.d/
h3:35:respawn:/etc/init.d/
So init.cssd is configured per normal CRS guidelines. So the problem is not that CRS is dying, it is most likely due to a heartbeat happening every second and program(s) or scripts being executed on that frequency. So my original analysis still stands, this is NORMAL behaviour. Let me know if you have questions about it.
Additionally, the probing for tls directories is due to the binaries compiled with multi-threaded support. ld is probing for the Linux Posix threads libc, also known as NPTL. If it exists, it will be loaded, if not, the usual libc is used with older, traditionally more stable LinuxThreads. At least up until a few Linux versions ago, Oracle did not support or run correctly running with NPTL, and required setting LD_ASSUME_KERNEL to a 2.4 version to forces use of the older LinuxThreads.
See Metalink note: 443475.1
You could probably cut-down on the probing for the NPTL library with a kernel configuration or switch. It used to be that you could use LD_ASSUME_KERNEL with 2.4 kernels, but that isn't simply an option now. I tried on recent Redhat 5, and it doesn't work for me.
I advise to research on Metalink and/or log a tar with Oracle for clarification on NPTL and tell them you want to configure your system such the audit logs are quieter due to this. It might be as simple as "Yes NPTL is supposed, and you are missing a library" or no, stay with what you have and reduce auditing.
Business Accounts
Answer for Membership
by: mrjoltcolaPosted on 2009-06-04 at 19:20:46ID: 24553038
1) All of those failed open calls are normal for program execution. When a program loads, the dynamic loader (ld) trys to load all those dynamic libraries based on LD_LIBRARY_PATH and/or explicit calls to ldopen, etc. If you use strace/ptrace on a given process, you will see all of the same failed attempts until ld locates the library it is looking for. So now, that tells us what the messages are.
BRAR Y_PATH :/bl ah/lib
2) Where are they coming from? They are coming from some programs being executed repeatedly. Looking at your log, it appears to be "pulsing" per second. It also has init.cssd involved, this is of course Oracle RAC cluster ready services. It is being re-spawned from /etc/inittab. Check your /etc/inittab and post the config here. Normally init.cssd is configured in "fatal" mode which means if it dies, the node reboots. I'm wondering if your node is somehow misconfigured without fatal mode, and init.cssd is respawning and dying over and over, but most likely it is NORMAL procedure. That is init.cssd's job, to keep the node/cluster alive.
Check your system log to see if you have any init ... respawning too fast messages.
In general, logging failed system calls at this level, on a busy system, can result in huge audit logs. The sheer volume of dynamic loading that goes on per second can and will generate this many "failed reads". To prove this, watch what happens when I issue a simple command from my Oracle environment and trace all failed opens (ENOENT).
First note, that my LD_LIBRARY_PATH has 1 directory in it, /oracle/11.1.0
I issue the command.
Then I add another dirrectory to the path
LD_LIBRARY_PATH=$LD_LI
And run it again. Double of the failed open calls. The more libs you have in your LD_LIBRARY_PATH, the more failed open / audit volume you are going to generate. So you can cut down jsut by removing unnecessary ones.
Bottom line, from me. You have way overconfigured your auditing for this type of active server.
Select allOpen in new window