RE: Listener.log not been updated

Paul,  

I did say that auditing connections is a consideration in my suggestion!  

Tom  

"Either a full log or turning the listener logging off will leave one completely blind to a remote dictionary-based attack (guessing passwords)."  

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Paul Drake
Sent: Wednesday, September 26, 2007 9:25 AM To: oracle-l
Subject: Re: Listener.log not been updated    

On 9/26/07, Mercadante, Thomas F (LABOR) <Thomas.Mercadante_at_labor.state.ny.us> wrote:

Steeve,  

I agree with John except for one thing. I leave listener_log status in the off position. Unless I need to debug something (or some folks have a need for auditing connections), this is a useless file, and it's just one more thing that needs to be managed.  

Oracle has a bad habit of creating audit log files and growing them all over the server with no option of turning them off. You don't know about them until the disk is full and you go searching for them. Whenever I have the option of turning one off, I usually do.  

Hope this helps.  

Tom

From: oracle-l-bounce_at_freelists.org [mailto: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> ] On Behalf Of John Hallas
Sent: Wednesday, September 26, 2007 3:52 AM To: bisst_at_touchtunes.com; oracle-l_at_freelists.org Subject: RE: Listener.log not been updated  

It must be an internal 4Gb limit within Oracle if you can create a larger file on the same server.  

TBH having a 4Gb is poor management anyway. Why not create a new one every week or so. It will be a lot easier to manage and if you do need to view it I think a 4Gb will be almost unreadable.  

From: oracle-l-bounce_at_freelists.org [mailto: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> ] On Behalf Of Steeve Bisson
Sent: 26 September 2007 02:20
To: oracle-l_at_freelists.org
Subject: Listener.log not been updated  

I am on Linux x86 OEL4 using Oracle 10.2.0.3.

My listener.log is not been updated since the 30 May.

cd /opt/oracle/app/oracle/product/10.2.0/db_1/network/log
[oracle_at_juk-prod log]$ ll

total 4203424
-rw-r--r-- 1 oracle oinstall 4294967428 May 30 21:49 listener.log

If I do status in lsnrctl:
Listener Parameter File
/opt/oracle/app/oracle/product/10.2.0/db_1/network/admin/listener.ora Listener Log File
/opt/oracle/app/oracle/product/10.2.0/db_1/network/log/listener.log

Everything else seems fine. I connect to the database with no problem. Any idea why the listener would stop writing log?

To solve the problem, I did the following in lsnrctl: SET LOG_FILE list.log

Now I get information in list.log
[oracle_at_juk-prod log]$ ll

total 4222736
-rw-r--r-- 1 oracle oinstall 4294967428 May 30 21:49 listener.log -rw-r--r-- 1 oracle oinstall 511462 Sep 16 19:41 list.log

Any idea why it would stop logging info once the log was at 4gig? I have 32GIG datafile on that machine.
Is there a thresholds where oracle stop to log, so it is possible to vi the log?
Anyone has documentation on this? Or a link on that subject?  

Either a full log or turning the listener logging off will leave one completely blind to a remote dictionary-based attack (guessing passwords).

As far as maximum file size, the block size has something to do with that.
You mentioned that you have a 32 GB datafile. Perhaps the db_block_size=8192 bytes?
I'm guessing that the block size for the filesystem on which the file listener.log resides is 1024 bytes.

Sorry, I'm not supposed to guess.
Would you mind supplying the database db_block_size and the filesystem block size for the file listener.log (under /opt/oracle/app)?

thanks,

Paul

--
http://www.freelists.org/webpage/oracle-l