Logging for non-existent listeners

While working on an 11gR1 database server today, I fat-fingered the name of a secondary listener (you know, practicing my stock-trading skills), and in the process I noticed something that I hadn't considered before. Here's the setup:

[oracle@11gr1srv ~]$ cd $DIAG_DIR/tnslsnr/11gr1srv
[oracle@11gr1srv 11gr1srv]$ ls
listener  listener_old
[oracle@11gr1srv 11gr1srv]$ lsnrctl start LISTENER_ODL

LSNRCTL for Linux: Version 11.1.0.7.0 - Production on 16-MAY-2010 13:09:10

Copyright (c) 1991, 2008, Oracle.  All rights reserved.

Starting /opt/oracle/app/oracle/product/11.1.0/dbhome_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.1.0.7.0 - Production
System parameter file is /opt/oracle/app/oracle/product/11.1.0/dbhome_1/network/admin/listener.ora
Log messages written to /opt/oracle/app/oracle/diag/tnslsnr/11gr1srv/listener_odl/alert/log.xml
TNS-01151: Missing listener name, LISTENER_ODL, in LISTENER.ORA

Listener failed to start. See the error message(s) above...

It looks like there are more consequences than brief embarrassment for that typo, though. My failed attempt to start the listener created a full Automatic Diagnostic Repository (ADR) directory structure for the non-existent listener:

[oracle@11gr1srv 11gr1srv]$ ls
listener  listener_odl  listener_old
[oracle@11gr1srv 11gr1srv]$ ls -R listener_odl
listener_odl:
alert  cdump  incident  incpkg  lck  metadata  stage  sweep  trace

listener_odl/alert:
log.xml

listener_odl/cdump:

listener_odl/incident:

listener_odl/incpkg:

listener_odl/lck:
AM_1096102193_3488045378.lck  AM_1744845641_3861997533.lck
AM_1096102262_3454819329.lck  AM_3216668543_3129272988.lck

listener_odl/metadata:
ADR_CONTROL.ams       INC_METER_IMPT_DEF.ams
ADR_INVALIDATION.ams  INC_METER_PK_IMPTS.ams

listener_odl/stage:

listener_odl/sweep:

listener_odl/trace:
listener_odl.log

I looked through the Net Services docs, but wasn't able to find a way to disable this behavior, and my Google-fu failed me as well. This only seems to be happening for the 'start' command; other lsnrctl commands (reload, status, stop, etc) just return the expected "TNS-01101: Could not find service name" response.

This sort of thing happens in 10g, too (and probably in older versions, I'm just too lazy to fire up my 9i test system), but the impact is much smaller: a single log file, not all of the ADR stuff that comes with 11g. Even in 11g, it's not a big deal; this just generates some light housecleaning work. At the extreme, I suppose it could be possible to launch the lamest DOS attack ever by chewing up lots of inodes, but there have to be more entertaining (and faster) ways to do that.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*